[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=306325#comment-306325 ] Alex Halovanic commented on MEAR-146: - I checked that empty library directory works for my use case with WebLogic too. But only in a way that worries me that these two scenarios don't entirely match up. Remember that /APP-INF/lib is the older WebLogic-specific magic library classpath and /lib is supposed to be the standardized location since EAR v5. These are the three scenarios defined according to the Sun XSD: # Element not present - search in /lib ## WebLogic searches /lib and in /APP-INF/lib and some other special external directories (exploded EARs, generic file overrides, etc.) # Element empty - disable searching ## WebLogic still searches in /APP-INF/lib and the external directories, but fails to search /lib. # Element defined - search in given directory ## WebLogic exclusively searches in this directory and ignores all others. So I think in Sean and my cases an empty element works, but *only* so long as we stick to the WebLogic specific APP-INF/lib defaultLibBundleDir. > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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:comment-tabpanel&focusedCommentId=306319#comment-306319 ] Sean Gurevich commented on MEAR-146: Defining a defaultLibBundleDir path for packaged libs and using a separate option to set the library-directory empty will work. Thanks. > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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-785) Arguments containing spaces and quotes cause the forked maven process to fail
[
https://jira.codehaus.org/browse/MRELEASE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306318#comment-306318
]
Robert Scholte commented on MRELEASE-785:
-
I'm wondering if I should just update this or write an IT for it too... Would
be very nice if we could prevent regression.
> Arguments containing spaces and quotes cause the forked maven process to fail
> -
>
> Key: MRELEASE-785
> URL: https://jira.codehaus.org/browse/MRELEASE-785
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: *nix
>Reporter: Rob Elliot
>Assignee: Robert Scholte
> Attachments: MRELEASE-785-maven-release-2.3.2.patch,
> MRELEASE-785-maven-release.patch
>
>
> The following config:
> {code:xml}
>
> maven-release-plugin
>
> forked-path
> false
> -Dgpg.passphrase="a phrase 'containing' quotes and
> spaces"
>
>
> {code}
> causes the forked clean verify to fail. This is preventing me using my gpg
> key as part of an automated release process.
> This is due to a bug in Plexus Utils which I have raised as issue 152
> PLXUTILS-152, and for which I have raised a pull request here:
> https://github.com/sonatype/plexus-utils/pull/5. I am raising an issue on
> the release plugin as when/if a fixed version of plexus utils is released the
> maven release plugin will need to upgrade to this new version to benefit.
--
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=306316#comment-306316 ] Stéphane Nicoll commented on MEAR-146: -- no that's no what I meant. Look at MEAR-151. Everything works as of now but the only difference is that we add an option to generate an empty library-directory element. I am talking about a *separate* option. If that works, then we can meet both requests with a single option (yours and MEAR-151). And I also think that "do not write library-directory", "write empty library-directory" and "write library directory with defaultLibBundleDir value" are too many options. It will be confusing. Thanks > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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-785) Arguments containing spaces and quotes cause the forked maven process to fail
[
https://jira.codehaus.org/browse/MRELEASE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte reassigned MRELEASE-785:
---
Assignee: Robert Scholte
> Arguments containing spaces and quotes cause the forked maven process to fail
> -
>
> Key: MRELEASE-785
> URL: https://jira.codehaus.org/browse/MRELEASE-785
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: *nix
>Reporter: Rob Elliot
>Assignee: Robert Scholte
> Attachments: MRELEASE-785-maven-release-2.3.2.patch,
> MRELEASE-785-maven-release.patch
>
>
> The following config:
> {code:xml}
>
> maven-release-plugin
>
> forked-path
> false
> -Dgpg.passphrase="a phrase 'containing' quotes and
> spaces"
>
>
> {code}
> causes the forked clean verify to fail. This is preventing me using my gpg
> key as part of an automated release process.
> This is due to a bug in Plexus Utils which I have raised as issue 152
> PLXUTILS-152, and for which I have raised a pull request here:
> https://github.com/sonatype/plexus-utils/pull/5. I am raising an issue on
> the release plugin as when/if a fixed version of plexus utils is released the
> maven release plugin will need to upgrade to this new version to benefit.
--
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-785) Arguments containing spaces and quotes cause the forked maven process to fail
[
https://jira.codehaus.org/browse/MRELEASE-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Elliot updated MRELEASE-785:
Attachment: MRELEASE-785-maven-release.patch
MRELEASE-785-maven-release-2.3.2.patch
Plexus Utils 3.0.4 has been released, which fixes this issue. These patches
upgrade to this version, and are valid for trunk & the 2.3.2 tag respectively.
> Arguments containing spaces and quotes cause the forked maven process to fail
> -
>
> Key: MRELEASE-785
> URL: https://jira.codehaus.org/browse/MRELEASE-785
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: *nix
>Reporter: Rob Elliot
> Attachments: MRELEASE-785-maven-release-2.3.2.patch,
> MRELEASE-785-maven-release.patch
>
>
> The following config:
> {code:xml}
>
> maven-release-plugin
>
> forked-path
> false
> -Dgpg.passphrase="a phrase 'containing' quotes and
> spaces"
>
>
> {code}
> causes the forked clean verify to fail. This is preventing me using my gpg
> key as part of an automated release process.
> This is due to a bug in Plexus Utils which I have raised as issue 152
> PLXUTILS-152, and for which I have raised a pull request here:
> https://github.com/sonatype/plexus-utils/pull/5. I am raising an issue on
> the release plugin as when/if a fixed version of plexus utils is released the
> maven release plugin will need to upgrade to this new version to benefit.
--
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-98) The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306185#comment-306185
]
James Davis edited comment on MDEP-98 at 8/15/12 3:17 PM:
--
As far as the comment about needing to do an install on the modules, that is
not always a desirable thing to do. If you have multiple builds running on the
same box with each of them installing, your build may end up getting the
artifact published by the other build, not the one from this build. The only
way to ensure you have the right contents is to use the artifact from the same
workspace.
As a side-note, I updated to the latest version (2.5) and used the package goal
and all seems to be working.
was (Author: davija):
As far as the comment about needing to do an install on the modules, that
is not always a desirable thing to do. If you have multiple builds running on
the same box with each of them installing, your build may end up getting the
artifact published by the other build, not the one from this build. The only
way to ensure you have the right contents is to use the artifact from the same
workspace.
> The source must not be a directory
> --
>
> Key: MDEP-98
> URL: https://jira.codehaus.org/browse/MDEP-98
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, 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
> Attachments: MDEP-98-ITs.patch,
> mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip
>
>
> 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 :
> {noformat}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.{noformat}
> Project structure is as follows:
> plataforma
> - platform-core
> - platform-bundle
> - platform-bundle-jar
> - platform
[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=306306#comment-306306 ] Sean Gurevich edited comment on MEAR-146 at 8/15/12 1:35 PM: - The jars need to be placed under APP-INF/lib of the EAR for newer versions of WebLogic to pick up libraries shared between WAR and EJB JAR, within the same application. The defaultLibBundleDir configuration option in Maven EAR plugin allows for putting all common libs under this specified directory. It also has the side effect of adding the library-directory element to the application.xml. An empty library-directory element would mean an empty defaultLibBundleDir argument, which would not package the common JARs where they need to be for WebLogic. Or do you have something else in mind? An alternative would be to provide an argument that works the same as "APP-INF/lib", but does not add the library-directory entry. Or an additional argument to override adding library-directory to the application.xml when using defaultLibBundleDir. The WebLogic-specific argument is certainly not the only approach to accomplish this. was (Author: seanpublic): The jars need to be placed under APP-INF/lib of the EAR for newer versions of WebLogic to pick up libraries shared between WAR and EJB JAR, within the same application. The defaultLibBundleDir configuration option in Maven EAR plugin puts all common libs under this specified directory. It also has the side effect of adding the library-directory element to the application.xml. An empty library-directory element would mean an empty defaultLibBundleDir argument, which would not package the common JARs where they need to be for WebLogic. Or do you have something else in mind? An alternative would be to provide an argument that works the same as "APP-INF/lib", but does not add the library-directory entry. Or an additional argument to override adding library-directory to the application.xml when using defaultLibBundleDir. The WebLogic-specific argument is certainly not the only approach to accomplish this. > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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:comment-tabpanel&focusedCommentId=306306#comment-306306 ] Sean Gurevich commented on MEAR-146: The jars need to be placed under APP-INF/lib of the EAR for newer versions of WebLogic to pick up libraries shared between WAR and EJB JAR, within the same application. The defaultLibBundleDir configuration option in Maven EAR plugin puts all common libs under this specified directory. It also has the side effect of adding the library-directory element to the application.xml. An empty library-directory element would mean an empty defaultLibBundleDir argument, which would not package the common JARs where they need to be for WebLogic. Or do you have something else in mind? An alternative would be to provide an argument that works the same as "APP-INF/lib", but does not add the library-directory entry. Or an additional argument to override adding library-directory to the application.xml when using defaultLibBundleDir. The WebLogic-specific argument is certainly not the only approach to accomplish this. > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306293#comment-306293
]
Rodion edited comment on MEAR-141 at 8/15/12 11:09 AM:
---
It was just what I mean :) - it was reverted, everybody agreed that it was
almost nothing to do with test failure and nobody have applied that patch back
for half of a year... I was thinking that may be there was something else
preventing from doing this?
was (Author: angrygami):
It was just what I mean :) - it was reverted, everybody agreed that it was
almost nothing to do with test failure and nobody have applied that patch back
for half of a year... I was thinking that may be there was something else
preventing from doing this that?
> No way to configure generate env-entry elements in generated application.xml
>
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stéphane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306293#comment-306293
]
Rodion commented on MEAR-141:
-
It was just what I mean :) - it was reverted, everybody agreed that it was
almost nothing to do with test failure and nobody have applied that patch back
for half of a year... I was thinking that may be there was something else
preventing from doing this that?
> No way to configure generate env-entry elements in generated application.xml
>
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stéphane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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=306292#comment-306292 ] Stéphane Nicoll commented on MEAR-146: -- Would MEAR-151 fix your issue? Because not writing the library directory will actually scan in the lib directory according to the spec. Can you try again with to see if that fixes your issue? In that case, I would go for MEAR-151 instead of adding a weblogic specific option. > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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 updated MEAR-146: - Fix Version/s: 2.8 > 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 >Priority: Minor > Fix For: 2.8 > > Attachments: 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-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 updated MEAR-151: - Fix Version/s: 2.8 > 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 > 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-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306291#comment-306291
]
Stéphane Nicoll commented on MEAR-141:
--
It does not work because the code was reverted. But now that I understand the
differences, we should document this and re-apply the patch indeed.
> No way to configure generate env-entry elements in generated application.xml
>
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stéphane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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-141) No way to configure generate env-entry elements in generated application.xml
[
https://jira.codehaus.org/browse/MEAR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306290#comment-306290
]
Rodion commented on MEAR-141:
-
Somebody have plans to restore functionality provided by 1235631? Feature still
doesn't work.
> No way to configure generate env-entry elements in generated application.xml
>
>
> Key: MEAR-141
> URL: https://jira.codehaus.org/browse/MEAR-141
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.6
>Reporter: Laird Nelson
>Assignee: Stéphane Nicoll
> Fix For: 2.8
>
>
> The maven-ear-plugin offers the {{security}} element for declaring
> security-role-names in a generated application.xml. It does not offer such a
> facility for generating {{env-entry}} elements. It should.
--
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] (MSITE-648) NoClassDefFoundError upgrading to Maven Site Plugin 3.1
[
https://jira.codehaus.org/browse/MSITE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Brandt closed MSITE-648.
Resolution: Cannot Reproduce
Closing as this seems unrelated to the site plugin.
> NoClassDefFoundError upgrading to Maven Site Plugin 3.1
> ---
>
> Key: MSITE-648
> URL: https://jira.codehaus.org/browse/MSITE-648
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Ian Brandt
> Attachments: build.log, MSITE-648.out
>
>
> When I update from 3.0 to 3.1 I get the error below. I've reproduced it on a
> couple projects, but here is a relatively simple POM that manifests the issue
> when updated:
> https://github.com/themadcreator/rabinfingerprint/blob/447cd065825b97e62a9b100f080ba217ba821de7/pom.xml
> {noformat}
> [INFO] --- maven-site-plugin:3.1:site (default-site) @ rabinfingerprint ---
> Aug 12, 2012 12:35:05 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
> WARNING: Error injecting:
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer
> java.lang.NoClassDefFoundError: org/apache/maven/doxia/logging/Log
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> [...]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.doxia.logging.Log
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> ... 89 more
> {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
[jira] (MSITE-648) NoClassDefFoundError upgrading to Maven Site Plugin 3.1
[
https://jira.codehaus.org/browse/MSITE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306213#comment-306213
]
Ian Brandt commented on MSITE-648:
--
I tried building with a fresh local repo via {{mvn
-Dmaven.repo.local=./.m2/repository site}}, and sure enough it works for me now
as well. It would seem I've picked up a bad dependency somehow:
{noformat}
$ sha1sum
/Users/ibrandt/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
38cb0021345de82b4b5463b90576318d4fe7e5fb
/Users/ibrandt/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
$ sha1sum
./.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
bc61324cc8ff649d0e50e4194e07bf6ed29b4531
./.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
{noformat}
{noformat}
$ unzip -t
/Users/ibrandt/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
Archive:
/Users/ibrandt/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
file #1: bad zipfile offset (local header sig): 0
file #2: bad zipfile offset (local header sig): 39
file #3: bad zipfile offset (local header sig): 298
file #4: bad zipfile offset (local header sig): 332
file #5: bad zipfile offset (local header sig): 373
file #6: bad zipfile offset (local header sig): 420
file #7: bad zipfile offset (local header sig): 473
file #8: bad zipfile offset (local header sig): 534
file #9: bad zipfile offset (local header sig): 907
testing: META-INF/NOTICE OK
testing: org/apache/maven/doxia/logging/Log.class OK
testing: org/apache/maven/doxia/logging/LogEnabled.class OK
testing: org/apache/maven/doxia/logging/PlexusLoggerWrapper.class OK
testing: org/apache/maven/doxia/logging/SystemStreamLog.class OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.doxia/ OK
testing: META-INF/maven/org.apache.maven.doxia/doxia-logging-api/ OK
testing: META-INF/maven/org.apache.maven.doxia/doxia-logging-api/pom.xml
OK
testing:
META-INF/maven/org.apache.maven.doxia/doxia-logging-api/pom.properties OK
At least one error was detected in
/Users/ibrandt/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar.
$ unzip -t
./.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
Archive:
./.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar
testing: META-INF/OK
testing: META-INF/MANIFEST.MF OK
testing: org/ OK
testing: org/apache/ OK
testing: org/apache/maven/OK
testing: org/apache/maven/doxia/ OK
testing: org/apache/maven/doxia/logging/ OK
testing: META-INF/DEPENDENCIESOK
testing: META-INF/LICENSE OK
testing: META-INF/NOTICE OK
testing: org/apache/maven/doxia/logging/Log.class OK
testing: org/apache/maven/doxia/logging/LogEnabled.class OK
testing: org/apache/maven/doxia/logging/PlexusLoggerWrapper.class OK
testing: org/apache/maven/doxia/logging/SystemStreamLog.class OK
testing: META-INF/maven/ OK
testing: META-INF/maven/org.apache.maven.doxia/ OK
testing: META-INF/maven/org.apache.maven.doxia/doxia-logging-api/ OK
testing: META-INF/maven/org.apache.maven.doxia/doxia-logging-api/pom.xml
OK
testing:
META-INF/maven/org.apache.maven.doxia/doxia-logging-api/pom.properties OK
No errors detected in compressed data of
./.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.3/doxia-logging-api-1.3.jar.
{noformat}
> NoClassDefFoundError upgrading to Maven Site Plugin 3.1
> ---
>
> Key: MSITE-648
> URL: https://jira.codehaus.org/browse/MSITE-648
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Ian Brandt
> Attachments: build.log, MSITE-648.out
>
>
> When I update from 3.0 to 3.1 I get the error below. I've reproduced it on a
> couple projects, but here is a relatively simple POM that manifests the issue
> when updated:
> https://github.com/themadcreator/rabinfingerprint/blob/447cd065825b97e62a9b100f080ba217ba821de7/pom.xml
> {noformat}
> [INFO] --- maven-site-plugin:3.1:site (default-site) @ rabinfingerprint ---
> Aug 12, 2012 12:35:05 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
> WARNING: Error injecting:
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer
> java.lang.NoClassDefFoundError: org/apache/maven/doxia/logging/Log
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> [...]
> Caused by: java.lang.ClassNotFoundException:
> o
[jira] (MSITE-648) NoClassDefFoundError upgrading to Maven Site Plugin 3.1
[
https://jira.codehaus.org/browse/MSITE-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306210#comment-306210
]
Ian Brandt commented on MSITE-648:
--
Just for completeness here is my diff to the above POM:
{noformat}
$ git diff
diff --git a/pom.xml b/pom.xml
index cfb3041..20e805a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -124,7 +124,7 @@
maven-site-plugin
- 3.0
+ 3.1
maven-source-plugin
{noformat}
> NoClassDefFoundError upgrading to Maven Site Plugin 3.1
> ---
>
> Key: MSITE-648
> URL: https://jira.codehaus.org/browse/MSITE-648
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Ian Brandt
> Attachments: build.log, MSITE-648.out
>
>
> When I update from 3.0 to 3.1 I get the error below. I've reproduced it on a
> couple projects, but here is a relatively simple POM that manifests the issue
> when updated:
> https://github.com/themadcreator/rabinfingerprint/blob/447cd065825b97e62a9b100f080ba217ba821de7/pom.xml
> {noformat}
> [INFO] --- maven-site-plugin:3.1:site (default-site) @ rabinfingerprint ---
> Aug 12, 2012 12:35:05 PM org.sonatype.guice.bean.reflect.Logs$JULSink warn
> WARNING: Error injecting:
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer
> java.lang.NoClassDefFoundError: org/apache/maven/doxia/logging/Log
> at java.lang.Class.getDeclaredConstructors0(Native Method)
> [...]
> Caused by: java.lang.ClassNotFoundException:
> org.apache.maven.doxia.logging.Log
> at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
> ... 89 more
> {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
[jira] (DOXIA-476) Doxia appends .html to file suffix when linking to a file with confluence markup
Tuukka Mustonen created DOXIA-476:
-
Summary: Doxia appends .html to file suffix when linking to a file
with confluence markup
Key: DOXIA-476
URL: https://jira.codehaus.org/browse/DOXIA-476
Project: Maven Doxia
Issue Type: Bug
Components: Module - Confluence
Affects Versions: 1.3
Reporter: Tuukka Mustonen
As reported in
http://jira.codehaus.org/browse/DOXIA-298?focusedCommentId=300128&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-300128,
caused by fix of http://jira.codehaus.org/browse/DOXIA-298
Adding a link to a file with Confluence markup causes generated HTML to always
append .html to the file suffix, causing linkage to fail.
To reproduce:
{code}
Click on this [link to a file|a-powerpoint-file.ppt]
{code}
Renders as:
{code}
Click on this link to a file
{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] (MNG-5329) sisu-guava is deprecated, use upstream library
[ https://jira.codehaus.org/browse/MNG-5329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=306205#comment-306205 ] Milos Kleint commented on MNG-5329: --- sisu-guava is also used in aether. > sisu-guava is deprecated, use upstream library > -- > > Key: MNG-5329 > URL: https://jira.codehaus.org/browse/MNG-5329 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies, General >Affects Versions: 3.0.4 >Reporter: Milos Kleint >Priority: Critical > > see https://github.com/sonatype/sisu-guava/tree/ > the sisu guava lib has been deprecated, from what I could figure from the > commit logs on original site and sisu-guava, the recently released 13.0 > release should be ok to use. -- 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] (MNG-5329) sisu-guava is deprecated, use upstream library
Milos Kleint created MNG-5329: - Summary: sisu-guava is deprecated, use upstream library Key: MNG-5329 URL: https://jira.codehaus.org/browse/MNG-5329 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies, General Affects Versions: 3.0.4 Reporter: Milos Kleint Priority: Critical see https://github.com/sonatype/sisu-guava/tree/ the sisu guava lib has been deprecated, from what I could figure from the commit logs on original site and sisu-guava, the recently released 13.0 release should be ok to use. -- 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
