[jira] (MEAR-60) Improve support for skinny war files

[Connor Barry (JIRA)]

[ 
https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=289096#comment-289096
 ] 

Connor Barry commented on MEAR-60:
--

Hi Andreas, I'm a little new to Maven internals but experiencing this exact 
problem as well. How did you configure your war plugin to use the 
non-timestamped version of the jar dependencies? I feel like that is a little 
cleaner than keeping the timestamp versions around in the EAR's APP-INF/lib 
folder.

 Improve support for skinny war files
 

 Key: MEAR-60
 URL: https://jira.codehaus.org/browse/MEAR-60
 Project: Maven 2.x Ear Plugin
  Issue Type: Improvement
Affects Versions: 2.3
 Environment: mvn 2.0.5
Reporter: Marcel Schutte
Assignee: Dennis Lundberg
Priority: Critical
 Fix For: 2.7

 Attachments: maven-ear-plugin-addon-1.0-SNAPSHOT.jar, 
 maven-ear-plugin-addon-1.0-SNAPSHOT-sources.jar, 
 maven-ear-plugin-MEAR-60.patch


 Provide a boolean configuration option for webModules to include the war's 
 transitive dependencies.
 As described on 
 http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it 
 is very common in a J2EE environment to use so called skinny wars. Here the 
 war's WEB-INF/lib will not contain the dependent jars, but instead they are 
 packaged inside the EAR. The war references them through its 
 META-INF/MANIFEST.MF
 This option could be used to avoid the 'painful part' mentioned in the above 
 web page. The war's dependencies wouldn't have to be duplicated alongside the 
 ear's.
 I also found an old issue (MEAR-14) which has asked for the current default 
 behavior of not including the transitive dependencies. It suggests a property 
 to include specific dependencies of the war. As far as I can tell this has 
 never been implemented and this is also not what I am asking for. My proposal 
 is an all of nothing kind of option for each war module in the ear.
 On a side note, for me this is the part where removal of the old maven 1 
 style properties per dependency is missed the most. With them it was possible 
 to decide for each single dependency whether to put it in WEB-INF/lib or 
 reference it through the manifest classpath. But of course, then we didn't 
 have the transitive dependencies

--
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] Commented: (MECLIPSE-165) Ability to exclude filtered resources from eclipse's source directories

[Connor Barry (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=155797#action_155797
 ] 

Connor Barry commented on MECLIPSE-165:
---

Any updates yet? This is really a crucial fix for anybody using filtered 
resources, which is a basic requirement of a lot of projects...

My workaround is to have a shell script that calls the maven goal, and 
additionally an ant script that modifies the resulting .classpath file to 
exclude ALL filtered resources, not only the **/*.java files. There's two 
regexes to account for the two possible attribute orders, which are seemingly 
random; just a hack, I'm sure there's a better way.

- eclipse-config.bat:
@echo off
setlocal

set _REALPATH=%~dp0
cd %_REALPATH%

cls
call %M2_HOME%/bin/mvn eclipse:clean eclipse:eclipse
call %ANT_HOME%/bin/ant fix-classpath
pause

- build.xml   (add a bogus env target if necessary):

?xml version=1.0?
project name=xxx default=env
target name=fix-classpath
echo message=Fixing the WTP settings... /
replaceregexp file=.classpath byline=true
regexp 
pattern='(.*)excluding=\*\*/\*\.java(.*)path=src/main/resources-filtered(.*)'
 /
substitution 
expression='\1excluding=**/*\2path=src/main/resources-filtered\3' /
/replaceregexp
replaceregexp file=.classpath byline=true
regexp 
pattern='(.*)path=src/main/resources-filtered(.*)excluding=\*\*/\*\.java(.*)'
 /
substitution 
expression='\1excluding=**/*\2path=src/main/resources-filtered\3' /
/replaceregexp
/target
/project


 Ability to exclude filtered resources from eclipse's source directories
 ---

 Key: MECLIPSE-165
 URL: http://jira.codehaus.org/browse/MECLIPSE-165
 Project: Maven 2.x Eclipse Plugin
  Issue Type: New Feature
  Components: PDE support
Affects Versions: 2.3
Reporter: Cédric Vidal
Assignee: Brian Fox
 Attachments: MECLIPSE-165.patch


 Resources should be in the classpath from Eclipse's point of view because 
 they end up being in the classpath from Maven 2's point of view, but whenever 
 resources are marked as being filtered by M2, Eclipse puts them unfiltered in 
 the classpath thus introducing an inconsistency between Maven 2 and Eclipse.
 Whether or not to include filtered resource directories in eclipse's sources 
 directories is therefore a real dilemna. While I'm sure a consistent solution 
 to this dilemna will eventually be found, it would be great to let the user 
 choose what to do in the meantime.
 The attached patch adresses this issue by adding a parameter, 
 'excludeFilteredResourcesFromSourceDirs', which when set to true prevents 
 filtered resource directories from being added to eclipse's source 
 directories. The parameter defaults to false to avoid changing current 
 projects' behavior.
 Regards,
 Cédric Vidal
 http://www.B-Process.com
 PS: This parameter could be overriden on a per resource directory basis as 
 mentionned in MECLIPSE-162. This is not adressed by the attached patch though

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira