maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Scholte (JIRA)" <j...@codehaus.org>
Subject [jira] (MEAR-167) Classes from different modules with the same artifactId are merged when skinnyWars set to TRUE
Date Thu, 14 Nov 2013 20:53:20 GMT

     [ https://jira.codehaus.org/browse/MEAR-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Robert Scholte updated MEAR-167:
--------------------------------

    Description: 
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>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-ear-plugin</artifactId>
			<version>2.8</version>
			<configuration>
				<skinnyWars>true</skinnyWars>
				<modules>
					<ejbModule>
						<groupId>main.root.ejb</groupId>
						<artifactId>service</artifactId>
						<uri>service1.jar</uri>
					</ejbModule>
					<ejbModule>
						<groupId>main.root.business</groupId>
						<artifactId>service</artifactId>
						<uri>service2.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.
   

  was:
When some modules, that are to be included in ear, have the same artifactId, classes from
those modules get merged.

Consider this project structure

.
|-root
|-app
|--business
|---service
|--ejb
|---service

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:

<build>
	<plugins>
		<plugin>
			<groupId>org.apache.maven.plugins</groupId>
			<artifactId>maven-ear-plugin</artifactId>
			<version>2.8</version>
			<configuration>
				<skinnyWars>true</skinnyWars>
				<modules>
					<ejbModule>
						<groupId>main.root.ejb</groupId>
						<artifactId>service</artifactId>
						<uri>service1.jar</uri>
					</ejbModule>
					<ejbModule>
						<groupId>main.root.business</groupId>
						<artifactId>service</artifactId>
						<uri>service2.jar</uri>
					</ejbModule>
				</modules>
			</configuration>
		</plugin>
	</plugins>
</build>

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):

workDirectory =
                    new File( new File( generatedDescriptorLocation, "temp" ), module.getArtifact().getArtifactId()
);
                workDirectory.mkdirs();

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.
   

    
> 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
>         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>
> 			<groupId>org.apache.maven.plugins</groupId>
> 			<artifactId>maven-ear-plugin</artifactId>
> 			<version>2.8</version>
> 			<configuration>
> 				<skinnyWars>true</skinnyWars>
> 				<modules>
> 					<ejbModule>
> 						<groupId>main.root.ejb</groupId>
> 						<artifactId>service</artifactId>
> 						<uri>service1.jar</uri>
> 					</ejbModule>
> 					<ejbModule>
> 						<groupId>main.root.business</groupId>
> 						<artifactId>service</artifactId>
> 						<uri>service2.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

Mime
View raw message