[jira] (MEAR-107) Cannot generate Eclipse file with eclipse:eclipse when dependent projects are not installed in repository
[
https://jira.codehaus.org/browse/MEAR-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MEAR-107.
---
Resolution: Not A Bug
Assignee: Robert Scholte
To be precise: this is not a bug of the maven-ear-plugin. When you call
{{eclipse:eclipse}} the maven-ear-plugin is not used at all. It is actually the
maven-eclipse-plugin which has issues with it.
To confirm: there are several
[integration-tests|http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-ear-plugin/src/it/]
in subversion which are multi modules and succeed without {{install}}.
Cannot generate Eclipse file with eclipse:eclipse when dependent projects are
not installed in repository
-
Key: MEAR-107
URL: https://jira.codehaus.org/browse/MEAR-107
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Reporter: Joost den Boer
Assignee: Robert Scholte
Attachments: MEAR-107-maven-ear-plugin-2.3.2.patch
In a multi module project, it is not possible to generate the Eclipse project
files of an Ear project when dependent projects are not installed in the
local repository.
This is caused by the GenerateApplicationXmlMojo which requires all
dependencies to be resolved before it is starten. The running of this mojo is
part of the Maven core lifecycle. Because of this bug it is also impossible
to build an ear package without installing all dependent projects in the
local repository first.
In our project we have a big multi module project. We chose not to checkin
all Eclipse project files (.project etc) in subversion. When a developer
checks out the project, he/she must be able to generate the Eclipse file
without having to compile, package and install all modules first.
It is very easy to reproduce this bug. Generate a new project using the
simple j2ee archetype and run eclipse:eclipse in the new project directory.
I created a patch for this bug. The solution is very easy. The
@requiresDependenciesResolution tag is removed from the
GenerateApplicationXmlMojo. In the AbstractEarMojo the dependencies are
resolved in the Mojo before the Ear Execution Context is created. For
dependency resolution I looked at how the Eclipse plugin and the Maven core
(for @requiresDependenciesResolution tags) implemented this. First the
dependencies are looked up in the local repository. The ear project should
only contain wars/jars of other modules and/or 3rd party libraries which are
used in those modules so it should not be necessary to download any
dependencies here. With this patch, the Ear plugin should work as it does
now. The new configuration property 'useProjectReferences' is default
'false'. When set to 'true' in the Ear configuration, missing dependencies
are lookup in the reactor and added to the project artifacts list.
With this fix it is possible to generate application xml and create and ear
package without having to install the project modules .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-155) Building multiple EARs containing different modules with classifiers doesn't work with skinnyWars set to true
[
https://jira.codehaus.org/browse/MEAR-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MEAR-155:
Description:
I have a multi-module project with following structure:
{noformat}
root
|- content
|- WAR
\- EAR
{noformat}
In which all modules (except root) generate 2 artifacts: a 'normal' artifact
(no classifier), that gets deployed on the server and a 'dev' artifact
(classifier=dev), that is used for local development.
This has worked fine until the skinnyWar was set to true:
The EAR-plugin now extracts the normal WAR into a temp-dir and repackages it.
Then it creates the EAR -- this version is alright.
When it wants to package the 'dev'-version, it extract the WAR into the SAME
directory as the previous WAR, repackages it and creates the EAR.
The problem here, is that the 'dev'-EAR now contains a 'dev'-WAR that has mixed
libraries inside -- both the 'normal' and 'dev' content-JAR!
Wouldn't it be better to either delete the temp-dir after creating the first
EAR or unpacking the module into a different temp-dir (eg including the
classifier in the name)?
was:
I have a multi-module project with following structure:
root
|- content
|- WAR
\- EAR
In which all modules (except root) generate 2 artifacts: a 'normal' artifact
(no classifier), that gets deployed on the server and a 'dev' artifact
(classifier=dev), that is used for local development.
This has worked fine until the skinnyWar was set to true:
The EAR-plugin now extracts the normal WAR into a temp-dir and repackages it.
Then it creates the EAR -- this version is alright.
When it wants to package the 'dev'-version, it extract the WAR into the SAME
directory as the previous WAR, repackages it and creates the EAR.
The problem here, is that the 'dev'-EAR now contains a 'dev'-WAR that has mixed
libraries inside -- both the 'normal' and 'dev' content-JAR!
Wouldn't it be better to either delete the temp-dir after creating the first
EAR or unpacking the module into a different temp-dir (eg including the
classifier in the name)?
Building multiple EARs containing different modules with classifiers doesn't
work with skinnyWars set to true
-
Key: MEAR-155
URL: https://jira.codehaus.org/browse/MEAR-155
Project: Maven Ear Plugin
Issue Type: Bug
Reporter: Roland Asmann
Attachments: MEAR-155.zip
I have a multi-module project with following structure:
{noformat}
root
|- content
|- WAR
\- EAR
{noformat}
In which all modules (except root) generate 2 artifacts: a 'normal' artifact
(no classifier), that gets deployed on the server and a 'dev' artifact
(classifier=dev), that is used for local development.
This has worked fine until the skinnyWar was set to true:
The EAR-plugin now extracts the normal WAR into a temp-dir and repackages it.
Then it creates the EAR -- this version is alright.
When it wants to package the 'dev'-version, it extract the WAR into the SAME
directory as the previous WAR, repackages it and creates the EAR.
The problem here, is that the 'dev'-EAR now contains a 'dev'-WAR that has
mixed libraries inside -- both the 'normal' and 'dev' content-JAR!
Wouldn't it be better to either delete the temp-dir after creating the first
EAR or unpacking the module into a different temp-dir (eg including the
classifier in the name)?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-142) bundleFileName ignored when plugin used with multiple profile
[
https://jira.codehaus.org/browse/MEAR-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MEAR-142.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte
This looks more like a Maven Core issue rather then a maven-ear-plugin issue.
However, when running the example project I get the results as expected.
I'd suggest to use a more recent version of Maven.
My system:
{noformat}
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: D:\apache-maven-3.0.5\bin\..
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_45\jre
Default locale: nl_NL, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
{noformat}
bundleFileName ignored when plugin used with multiple profile
-
Key: MEAR-142
URL: https://jira.codehaus.org/browse/MEAR-142
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: linux, or windows same behaviour
maven 2, jdk 1.5
Reporter: Stefano Ghezzi
Assignee: Robert Scholte
Attachments: ear-bundle-file-name.zip
I want to build ear with different sets of modules based on the profiles
activated
In every profile i have a configuration like this
{code:xml}
profile
idprofile1/id
dependencies
dependency
..
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
configuration
modules
ejbModule
groupId/groupId
artifactIdxxx-yyy/artifactId
bundleFileNamexxx-yyy.jar/bundleFileName
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
/profile
{code}
As soon as i use two different profiles the bundleFileName attribute is
ignored and ejb/jar/war are packaged with the original filename
Only workaround possibile at the moment:
have only two profiles
replicate all the ejb/jar/war in the two profiles
but obviously this is less than optimal
bye
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-88) Improve documentation on combining Eclipse and Maven Integration
[
https://jira.codehaus.org/browse/MEAR-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335767#comment-335767
]
Robert Scholte commented on MEAR-88:
Is it still worth adding this page? I'd expect that both Eclipse and the
M2Eclipse integration are mature enough to support this without specific
adjustments.
Improve documentation on combining Eclipse and Maven Integration
Key: MEAR-88
URL: https://jira.codehaus.org/browse/MEAR-88
Project: Maven Ear Plugin
Issue Type: Improvement
Reporter: Chris Graham
Priority: Trivial
This could be implemented as another example.
Eclipse and Maven Integration
If you have used mvn eclipse:eclipse to generate the metadata for an EAR
project, it will want the application.xml file in the
src\main\application\META-INF directory.
If you edit application.xml using the WTP based Application Deployment
Descriptor editor, it will use the name of the projects (Web, EJB etc) as the
name of the modules. Here is an example:
?xml version=1.0 encoding=UTF-8?
application xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd; version=1.4
display-nameFireDragon/display-name
module
web
web-uriFireDragonWeb.war/web-uri
context-rootfiredragon/context-root
/web
/module
/application
Obviously this does not have the typical maven based version naming
convention applied to it. This allows us to run the application internally
within eclipse/rsa using the test environments.
However, when maven is used to create the ear using mvn package, it will
create the versionised application.xml file, if told to. However, by default
it will not pick up the generated (versionized) one, it will use the existing
one in the src\main\application\META-INF directory.
The solution to resolve this conflict is to have maven generate the
application.xml and use the generated one as opposed to the existing one.
This can be achieved via these two directives:
generateApplicationXmltrue/generateApplicationXml
applicationXml${project.build.directory}/application.xml/applicationXml
The first line tells maven to generate a new application.xml file, by default
in the target directory.
The second line tells maven to use it.
Simple!
-Chris
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-88) Improve documentation on combining Eclipse and Maven Integration
[
https://jira.codehaus.org/browse/MEAR-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MEAR-88:
---
Description:
This could be implemented as another example.
Eclipse and Maven Integration
If you have used {{mvn eclipse:eclipse}} to generate the metadata for an EAR
project, it will want the {{application.xml}} file in the
{{src\main\application\META-INF}} directory.
If you edit application.xml using the WTP based Application Deployment
Descriptor editor, it will use the name of the projects (Web, EJB etc) as the
name of the modules. Here is an example:
{code:xml}
?xml version=1.0 encoding=UTF-8?
application xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd; version=1.4
display-nameFireDragon/display-name
module
web
web-uriFireDragonWeb.war/web-uri
context-rootfiredragon/context-root
/web
/module
/application
{code}
Obviously this does not have the typical maven based version naming convention
applied to it. This allows us to run the application internally within
eclipse/rsa using the test environments.
However, when maven is used to create the ear using mvn package, it will create
the versionised application.xml file, if told to. However, by default it will
not pick up the generated (versionized) one, it will use the existing one in
the {{src\main\application\META-INF}} directory.
The solution to resolve this conflict is to have maven generate the
application.xml and use the generated one as opposed to the existing one.
This can be achieved via these two directives:
{code:xml}
generateApplicationXmltrue/generateApplicationXml
applicationXml${project.build.directory}/application.xml/applicationXml
{code}
The first line tells maven to generate a new application.xml file, by default
in the target directory.
The second line tells maven to use it.
Simple!
-Chris
was:
This could be implemented as another example.
Eclipse and Maven Integration
If you have used mvn eclipse:eclipse to generate the metadata for an EAR
project, it will want the application.xml file in the
src\main\application\META-INF directory.
If you edit application.xml using the WTP based Application Deployment
Descriptor editor, it will use the name of the projects (Web, EJB etc) as the
name of the modules. Here is an example:
?xml version=1.0 encoding=UTF-8?
application xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd; version=1.4
display-nameFireDragon/display-name
module
web
web-uriFireDragonWeb.war/web-uri
context-rootfiredragon/context-root
/web
/module
/application
Obviously this does not have the typical maven based version naming convention
applied to it. This allows us to run the application internally within
eclipse/rsa using the test environments.
However, when maven is used to create the ear using mvn package, it will create
the versionised application.xml file, if told to. However, by default it will
not pick up the generated (versionized) one, it will use the existing one in
the src\main\application\META-INF directory.
The solution to resolve this conflict is to have maven generate the
application.xml and use the generated one as opposed to the existing one.
This can be achieved via these two directives:
generateApplicationXmltrue/generateApplicationXml
applicationXml${project.build.directory}/application.xml/applicationXml
The first line tells maven to generate a new application.xml file, by default
in the target directory.
The second line tells maven to use it.
Simple!
-Chris
Improve documentation on combining Eclipse and Maven Integration
Key: MEAR-88
URL: https://jira.codehaus.org/browse/MEAR-88
Project: Maven Ear Plugin
Issue Type: Improvement
Reporter: Chris Graham
Priority: Trivial
This could be implemented as another example.
Eclipse and Maven Integration
If you have used {{mvn eclipse:eclipse}} to generate the metadata for an EAR
project, it will want the {{application.xml}} file in the
{{src\main\application\META-INF}} directory.
If you edit application.xml using the WTP based Application Deployment
Descriptor editor, it will use the name of the projects (Web, EJB etc) as the
name of the modules. Here is an example:
{code:xml}
?xml version=1.0 encoding=UTF-8?
application xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd;
[jira] (MEAR-167) Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE
[
https://jira.codehaus.org/browse/MEAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MEAR-167.
---
Resolution: Fixed
Fix Version/s: 2.9
Assignee: Robert Scholte
Fixed in [r1542525|http://svn.apache.org/r1542525]
Thanks for the example!
Classes from different modules with the same artifactId are merged when
skinnyWars set to TRUE
--
Key: MEAR-167
URL: https://jira.codehaus.org/browse/MEAR-167
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Reporter: Anton Shaykin
Assignee: Robert Scholte
Fix For: 2.9
Attachments: example.zip
When some modules, that are to be included in ear, have the same artifactId,
classes from those modules get merged.
Consider this project structure
{noformat}
.
|-root
|-app
|--business
|---service
|--ejb
|---service
{noformat}
In this example, there are 2 ejb modules main.root.business:service:jar and
main.root.ejb:service:jar with artifactId 'service'.
Project app has the following build configuration:
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.8/version
configuration
skinnyWarstrue/skinnyWars
modules
ejbModule
groupIdmain.root.ejb/groupId
artifactIdservice/artifactId
uriservice1.jar/uri
/ejbModule
ejbModule
groupIdmain.root.business/groupId
artifactIdservice/artifactId
uriservice2.jar/uri
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
{code}
When I run {{maven-ear-plugin:ear}} goal I get an ear with 2 ejb jars in it
(service1.jar and service2.jar), but the second one contains classes from
both modules.
I did some code digging, and this is what I've found (EarMojo, line 684):
{code}
workDirectory =
new File( new File( generatedDescriptorLocation, temp
), module.getArtifact().getArtifactId() );
workDirectory.mkdirs();
{code}
So, basically, when skinnyWars set to TRUE, you create a temporary folder
with the name based on artifactId. That's why the classes are merged in the
second jar.
As a solution, I'd suggest either randomize the directory name, or at least
check for a directory existence and remove it recursively, if found.
The example project is attached to this ticket.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-173) EJB Modules defined in a parent POM are ignored from the child POM
[
https://jira.codehaus.org/browse/MEAR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MEAR-173.
---
Resolution: Cannot Reproduce
Assignee: Robert Scholte
EJB Modules defined in a parent POM are ignored from the child POM
--
Key: MEAR-173
URL: https://jira.codehaus.org/browse/MEAR-173
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: Windows XP 64bits
Reporter: Benoît Berthonneau
Assignee: Robert Scholte
Priority: Critical
Attachments: MEAR-173.zip
When a parent pom (pom packaging) defines ejbModules in the configuration
section, these ejbModules are ignored in a child module (ear packaging)
The others modules (jar, war) are correctly taken into account.
Here is the pom structure:
{noformat}
parent-ear (with ejbModules defined, common to all child modules)
| ear-1 (with specific ejbModules)
| ear-2 (with other specific ejbModules)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-173) EJB Modules defined in a parent POM are ignored from the child POM
[
https://jira.codehaus.org/browse/MEAR-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MEAR-173:
Attachment: MEAR-173.zip
This sounds more like a Maven Core issue then a maven-ear-plugin issue. I've
created a sample project which should reflect your usecase, but I couldn't
reproduce the issue.
EJB Modules defined in a parent POM are ignored from the child POM
--
Key: MEAR-173
URL: https://jira.codehaus.org/browse/MEAR-173
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Environment: Windows XP 64bits
Reporter: Benoît Berthonneau
Priority: Critical
Attachments: MEAR-173.zip
When a parent pom (pom packaging) defines ejbModules in the configuration
section, these ejbModules are ignored in a child module (ear packaging)
The others modules (jar, war) are correctly taken into account.
Here is the pom structure:
{noformat}
parent-ear (with ejbModules defined, common to all child modules)
| ear-1 (with specific ejbModules)
| ear-2 (with other specific ejbModules)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-167) Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE
[
https://jira.codehaus.org/browse/MEAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335774#comment-335774
]
Anton Shaykin commented on MEAR-167:
@Robert Scholte, You're welcome. Thanks for the fix! When could we expect the
new release of maven-ear-plugin?
Classes from different modules with the same artifactId are merged when
skinnyWars set to TRUE
--
Key: MEAR-167
URL: https://jira.codehaus.org/browse/MEAR-167
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Reporter: Anton Shaykin
Assignee: Robert Scholte
Fix For: 2.9
Attachments: example.zip
When some modules, that are to be included in ear, have the same artifactId,
classes from those modules get merged.
Consider this project structure
{noformat}
.
|-root
|-app
|--business
|---service
|--ejb
|---service
{noformat}
In this example, there are 2 ejb modules main.root.business:service:jar and
main.root.ejb:service:jar with artifactId 'service'.
Project app has the following build configuration:
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.8/version
configuration
skinnyWarstrue/skinnyWars
modules
ejbModule
groupIdmain.root.ejb/groupId
artifactIdservice/artifactId
uriservice1.jar/uri
/ejbModule
ejbModule
groupIdmain.root.business/groupId
artifactIdservice/artifactId
uriservice2.jar/uri
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
{code}
When I run {{maven-ear-plugin:ear}} goal I get an ear with 2 ejb jars in it
(service1.jar and service2.jar), but the second one contains classes from
both modules.
I did some code digging, and this is what I've found (EarMojo, line 684):
{code}
workDirectory =
new File( new File( generatedDescriptorLocation, temp
), module.getArtifact().getArtifactId() );
workDirectory.mkdirs();
{code}
So, basically, when skinnyWars set to TRUE, you create a temporary folder
with the name based on artifactId. That's why the classes are merged in the
second jar.
As a solution, I'd suggest either randomize the directory name, or at least
check for a directory existence and remove it recursively, if found.
The example project is attached to this ticket.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-167) Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE
[
https://jira.codehaus.org/browse/MEAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335775#comment-335775
]
Robert Scholte commented on MEAR-167:
-
Soon, see http://markmail.org/message/3pq7wlzgdq5wzlfa
Classes from different modules with the same artifactId are merged when
skinnyWars set to TRUE
--
Key: MEAR-167
URL: https://jira.codehaus.org/browse/MEAR-167
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.8
Reporter: Anton Shaykin
Assignee: Robert Scholte
Fix For: 2.9
Attachments: example.zip
When some modules, that are to be included in ear, have the same artifactId,
classes from those modules get merged.
Consider this project structure
{noformat}
.
|-root
|-app
|--business
|---service
|--ejb
|---service
{noformat}
In this example, there are 2 ejb modules main.root.business:service:jar and
main.root.ejb:service:jar with artifactId 'service'.
Project app has the following build configuration:
{code:xml}
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.8/version
configuration
skinnyWarstrue/skinnyWars
modules
ejbModule
groupIdmain.root.ejb/groupId
artifactIdservice/artifactId
uriservice1.jar/uri
/ejbModule
ejbModule
groupIdmain.root.business/groupId
artifactIdservice/artifactId
uriservice2.jar/uri
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
{code}
When I run {{maven-ear-plugin:ear}} goal I get an ear with 2 ejb jars in it
(service1.jar and service2.jar), but the second one contains classes from
both modules.
I did some code digging, and this is what I've found (EarMojo, line 684):
{code}
workDirectory =
new File( new File( generatedDescriptorLocation, temp
), module.getArtifact().getArtifactId() );
workDirectory.mkdirs();
{code}
So, basically, when skinnyWars set to TRUE, you create a temporary folder
with the name based on artifactId. That's why the classes are merged in the
second jar.
As a solution, I'd suggest either randomize the directory name, or at least
check for a directory existence and remove it recursively, if found.
The example project is attached to this ticket.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) provided scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335779#comment-335779 ] Tibor Digana commented on MNG-2205: --- I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. You can see this problem in the zip file in subdirectory problem. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. See the folder without profiles and with parents. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx provided scope dependencies must be transitive Key: MNG-2205 URL: https://jira.codehaus.org/browse/MNG-2205 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: David Boden Priority: Critical Fix For: 3.x / Backlog Attachments: transitivetest.zip A provided scope dependency can also be thought of as compile-only. Project A requires Sybase JConnect on the runtime classpath. Project A declares a provided dependency on Sybase JConnect. Project B depends upon Project A. Project B declares a compile dependency on Project A. Project C depends upon Project B. Project C declares a compile dependency on Project B. C | - compile dependency B | - compile dependency A | - provided dependency Sybase JConnect So, does Project C transitively depend on Sybase JConnect. Yes, of course! The provided dependency needs to be transitive. Ultimately, when Project C gets deployed, Sybase JConnect needs to be somewhere on the runtime classpath in order for the application to function. It's valid for Project C to assume that Sybase JConnect is available and use JDBC all over the Project C code. Project C is safe to do this because it can happily deduce that Sybase JConnect will be there in the runtime environment because Project A NEEDS IT. I've got Use Cases all over my aggregated build which make it absolutely critical and common sense that provided scope dependencies are transitive. For the (very rare) odd case where you don't want to inherit provided dependencies, you can exclude/ them. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) provided scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:12 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. You can see this problem in the zip file in subdirectory problem. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. See the folder without profiles and with parents. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx provided scope dependencies must be transitive Key: MNG-2205 URL: https://jira.codehaus.org/browse/MNG-2205 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: David Boden Priority: Critical Fix For: 3.x / Backlog Attachments: transitivetest.zip A provided scope dependency can also be thought of as compile-only. Project A requires Sybase JConnect on the runtime classpath. Project A declares a provided dependency on Sybase JConnect. Project B depends upon Project A. Project B declares a compile dependency on Project A. Project C depends upon Project B. Project C declares a compile dependency on Project B. C | - compile dependency B | - compile
[jira] (MNG-2205) provided scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:14 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a worakaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx provided scope dependencies must be transitive Key: MNG-2205 URL: https://jira.codehaus.org/browse/MNG-2205 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: David Boden Priority: Critical Fix For: 3.x / Backlog Attachments: transitivetest.zip A provided scope dependency can also be thought of as compile-only. Project A requires Sybase JConnect on the runtime classpath. Project A declares a provided dependency on Sybase JConnect. Project B depends upon Project A. Project B declares a compile dependency on Project A. Project C depends upon Project B. Project C declares a compile dependency on Project B. C | - compile dependency B | - compile dependency A | - provided dependency Sybase JConnect So, does Project C transitively depend on Sybase JConnect. Yes, of
[jira] (MNG-2205) provided scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:17 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround can be used to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. The Services-BOM and DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround can be used to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx provided scope dependencies must be transitive Key: MNG-2205 URL: https://jira.codehaus.org/browse/MNG-2205 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: David Boden Priority: Critical Fix For: 3.x / Backlog Attachments: transitivetest.zip A provided scope dependency can also be thought of as compile-only. Project A requires Sybase JConnect on the runtime classpath. Project A declares a provided dependency on Sybase JConnect. Project B depends upon Project A. Project B declares a compile dependency on Project A. Project C depends upon Project B. Project C declares a compile dependency on Project B. C | - compile dependency B | - compile dependency A | - provided dependency Sybase JConnect So, does Project C transitively depend on Sybase
[jira] (MNG-2205) provided scope dependencies must be transitive
[ https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335779#comment-335779 ] Tibor Digana edited comment on MNG-2205 at 11/16/13 4:16 PM: - I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround can be used to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx was (Author: tibor17): I am using Maven 3.1.1 This bug is very important and needs to be fixed. Especially in Java enterprise architecture the transitive scope of provided is used. You have inheritance of modules + parent in reactor: webapp module inherits(war) - services(jar) - dao(jar) So the DAO is dependent on Hibernate. The own Hibernate's dependencies (like. hibernate-jpa-2.0-api, ...) should be excluded, but the same javax artifacts should be included with the scope provided. The scope=provided on e.g. JPA API is necessary because we want to have own Hibernate's dependencie in compile time and tests as well. Additionally, the WAR file should NOT have libraries with javax packages in WEB-INF/lib. If you compile DAO module only, it succeeds. In reality you compile the parent POM in reactor, the build fails in module services. The class from provided artifact was not inherited by the module services. The webapp module wouldn't inherit it either. So the people make a workaround so that they put the same dependency with provided scope in module services or all modules. This is terrible because: + the inheritance in Maven is then useless + you duplicated the same dependencies with same scope + more work when maintaining the modules + the POM files are huge So the temporary workaround would be to create parents Services-BOM and DAO-BOM with packaging=pom. Inheritance: Services-BOM - DAO-BOM - reactor's POM The DAO will have parent DAO-BOM with provided artifacts, and services will have parent Services-BOM. The problem with this impractical workaround is that you cannot use profiles otherwise you are on the beginning again. Services-BOM - DAO-BOM have no noition of profiles in Maven 3.1.1. You need the profile bacause the build needs to be customized for different appication servers and anything else. Thx provided scope dependencies must be transitive Key: MNG-2205 URL: https://jira.codehaus.org/browse/MNG-2205 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Reporter: David Boden Priority: Critical Fix For: 3.x / Backlog Attachments: transitivetest.zip A provided scope dependency can also be thought of as compile-only. Project A requires Sybase JConnect on the runtime classpath. Project A declares a provided dependency on Sybase JConnect. Project B depends upon Project A. Project B declares a compile dependency on Project A. Project C depends upon Project B. Project C declares a compile dependency on Project B. C | - compile dependency B | - compile dependency A | - provided dependency Sybase JConnect So, does Project C transitively depend on Sybase JConnect. Yes, of
[jira] (MEAR-162) skinnyWars with wars without manifest Class-Path attribute
[ https://jira.codehaus.org/browse/MEAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MEAR-162. --- Resolution: Fixed Fix Version/s: 2.9 Assignee: Robert Scholte Fixed in [r1542608|http://svn.apache.org/r1542608] Thanks for the patches! skinnyWars with wars without manifest Class-Path attribute -- Key: MEAR-162 URL: https://jira.codehaus.org/browse/MEAR-162 Project: Maven Ear Plugin Issue Type: Bug Affects Versions: 2.8 Reporter: Laszlo Varadi Assignee: Robert Scholte Fix For: 2.9 Attachments: EarMojo.patch, Manifest_Class-Path-Bug.patch, MEAR-162.patch The classpath attribute should be set after populating with values, otherwise the classpath will be empty in the war manifest in case when the attribute is a newly created attribute. See patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEAR-148) In an ear which has skinny wars, want to include the same jar in shared lib of ear as well as in the war
[
https://jira.codehaus.org/browse/MEAR-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=335781#comment-335781
]
Robert Scholte commented on MEAR-148:
-
I've seen comparable projects which were originally built with Ant. In order to
get the same ear something like this was required.
It is indeed something which has to be solved per webmodule, but I would
suggest a different way of configuration:
{code:xml}
webModule
groupIdmy.groupId/groupId
artifactIdmy.artifactId/artifactId
skinnedDependencies
includes
includegroupId:artifactId[:type[:classifier]]/include !-- default
*:* which means everything--
/includes
excludes
excludegroupId:artifactId[:type[:classifier]]/exclude
/excludes
/skinnedDependencies
/webModule
{code}
Not sure if {{skinnedDependencies}} is the right/best term.
In an ear which has skinny wars, want to include the same jar in shared lib
of ear as well as in the war
Key: MEAR-148
URL: https://jira.codehaus.org/browse/MEAR-148
Project: Maven Ear Plugin
Issue Type: New Feature
Affects Versions: 2.7
Reporter: Tejas Pajai
I have the following artifacts
MyWar1.war depends on MyJar.jar and SomeThirdParty.jar
MyWar2.war depends on MyJar.jar
MyJar.jar also depends on SomeThirdParty.jar
Now I want to create an ear with MyWar1 and MyWar2, and I want to make them
skinny wars so that MyJar.jar should not be included in both the wars.
For some reason, the SomeThirdParty.jar has to be in the WEB-INF/lib
directory of MyWar1.war
Here is the structure I want:
{noformat}
MyEar.ear
- lib
- MyJar.jar
- SomeThirdParty.jar
- MyWar1.war
- WEB-INF/lib/SomeThirdParty.jar
- MyWar1.war
{noformat}
*As you can see, I want the SomeThirdParty.jar in MyWar1 as well as in the
lib directory.*
*Is there any way to achieve it if I am using skinnyWarstrue/skinnyWars?*
If not, we should have some way of doing this, maybe by supporting nested
dependencies in the webmodule tag which would override the skinnyWars
behavior for the listed dependencies like
{noformat}
webModule
groupIdmy.groupId/groupId
artifactIdmy.artifactId/artifactId
dependencies
dependency
groupIdSomeThirdParty.jar.groupId/groupId
artifactIdSomeThirdParty.jar/artifactId
versionSomeThirdParty.jar.version/version
/dependency
/dependencies
/webModule
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2205) provided scope dependencies must be transitive
[
https://jira.codehaus.org/browse/MNG-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MNG-2205:
Description:
A provided scope dependency can also be thought of as compile-only.
Project A requires Sybase JConnect on the runtime classpath. Project A declares
a provided dependency on Sybase JConnect.
Project B depends upon Project A. Project B declares a compile dependency on
Project A.
Project C depends upon Project B. Project C declares a compile dependency on
Project B.
{noformat}
C
| - compile dependency
B
| - compile dependency
A
| - provided dependency
Sybase JConnect
{noformat}
So, does Project C transitively depend on Sybase JConnect. Yes, of course! The
provided dependency needs to be transitive.
Ultimately, when Project C gets deployed, Sybase JConnect needs to be somewhere
on the runtime classpath in order for the application to function. It's valid
for Project C to assume that Sybase JConnect is available and use JDBC all over
the Project C code. Project C is safe to do this because it can happily deduce
that Sybase JConnect will be there in the runtime environment because Project A
NEEDS IT.
I've got Use Cases all over my aggregated build which make it absolutely
critical and common sense that provided scope dependencies are transitive. For
the (very rare) odd case where you don't want to inherit provided dependencies,
you can exclude/ them.
was:
A provided scope dependency can also be thought of as compile-only.
Project A requires Sybase JConnect on the runtime classpath. Project A declares
a provided dependency on Sybase JConnect.
Project B depends upon Project A. Project B declares a compile dependency on
Project A.
Project C depends upon Project B. Project C declares a compile dependency on
Project B.
C
| - compile dependency
B
| - compile dependency
A
| - provided dependency
Sybase JConnect
So, does Project C transitively depend on Sybase JConnect. Yes, of course! The
provided dependency needs to be transitive.
Ultimately, when Project C gets deployed, Sybase JConnect needs to be somewhere
on the runtime classpath in order for the application to function. It's valid
for Project C to assume that Sybase JConnect is available and use JDBC all over
the Project C code. Project C is safe to do this because it can happily deduce
that Sybase JConnect will be there in the runtime environment because Project A
NEEDS IT.
I've got Use Cases all over my aggregated build which make it absolutely
critical and common sense that provided scope dependencies are transitive. For
the (very rare) odd case where you don't want to inherit provided dependencies,
you can exclude/ them.
provided scope dependencies must be transitive
Key: MNG-2205
URL: https://jira.codehaus.org/browse/MNG-2205
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Reporter: David Boden
Priority: Critical
Fix For: 3.x / Backlog
Attachments: transitivetest.zip
A provided scope dependency can also be thought of as compile-only.
Project A requires Sybase JConnect on the runtime classpath. Project A
declares a provided dependency on Sybase JConnect.
Project B depends upon Project A. Project B declares a compile dependency
on Project A.
Project C depends upon Project B. Project C declares a compile dependency
on Project B.
{noformat}
C
| - compile dependency
B
| - compile dependency
A
| - provided dependency
Sybase JConnect
{noformat}
So, does Project C transitively depend on Sybase JConnect. Yes, of course!
The provided dependency needs to be transitive.
Ultimately, when Project C gets deployed, Sybase JConnect needs to be
somewhere on the runtime classpath in order for the application to function.
It's valid for Project C to assume that Sybase JConnect is available and use
JDBC all over the Project C code. Project C is safe to do this because it can
happily deduce that Sybase JConnect will be there in the runtime environment
because Project A NEEDS IT.
I've got Use Cases all over my aggregated build which make it absolutely
critical and common sense that provided scope dependencies are transitive.
For the (very rare) odd case where you don't want to inherit provided
dependencies, you can exclude/ them.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
