[jira] Issue Comment Edited: (MWAR-182) warSourceIncludes no longer works

2009-02-18 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166117#action_166117
 ] 

Bryan Loofbourrow edited comment on MWAR-182 at 2/18/09 1:14 PM:
-

Re: comment just above: You need to add some more things to your 
packagingIncludes to tell the plugin to package those things in the war. Try:

{noformat}WEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css{noformat}

This issue is discussed two comments above yours.

  was (Author: bryanloof):
Re: comment just above: You need to add some more things to your 
packagingIncludes to tell the plugin to package those things in the war. Try:

WEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css

This issue is discussed two comments above yours.
  
> warSourceIncludes no longer works
> -
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
>Reporter: Bryan Loofbourrow
>Assignee: Dennis Lundberg
> Fix For: 2.1-beta-1
>
> Attachments: pom.xml
>
>
> The  element no longer seems to work, as of 2.1-alpha-2. 
> It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
> demonstrate the problem when used as follows:
> 1) From the directory containing the pom.xml, create a web.xml, because 
> otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
>   mkdir -p src/main/webapp/WEB-INF
>   touch src/main/webapp/WEB-INF/web.xml
> 2) Build with the 2.1-alpha-1 plugin
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 3) Dump out the jar contents to verify that only commons-logging and the 
> web.xml were packaged, as requested
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/lib/
> WEB-INF/lib/commons-logging-1.1.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties
> 4) Now build using the 2.1-alpha-2 plugin version:
>  mvn clean install -Dwar.plugin.version=2.1-alpha-2
> 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
> this time:
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/classes/
> WEB-INF/lib/
> WEB-INF/web.xml
> WEB-INF/lib/commons-logging-1.1.jar
> WEB-INF/lib/log4j-1.2.12.jar
> WEB-INF/lib/logkit-1.0.1.jar
> WEB-INF/lib/avalon-framework-4.1.3.jar
> WEB-INF/lib/servlet-api-2.3.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties

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




[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-18 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166117#action_166117
 ] 

Bryan Loofbourrow commented on MWAR-182:


Re: comment just above: You need to add some more things to your 
packagingIncludes to tell the plugin to package those things in the war. Try:

WEB-INF/lib/junit*.jar,**/*.xml,**/*.class,**/*.css

This issue is discussed two comments above yours.

> warSourceIncludes no longer works
> -
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
>Reporter: Bryan Loofbourrow
>Assignee: Dennis Lundberg
> Fix For: 2.1-beta-1
>
> Attachments: pom.xml
>
>
> The  element no longer seems to work, as of 2.1-alpha-2. 
> It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
> demonstrate the problem when used as follows:
> 1) From the directory containing the pom.xml, create a web.xml, because 
> otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
>   mkdir -p src/main/webapp/WEB-INF
>   touch src/main/webapp/WEB-INF/web.xml
> 2) Build with the 2.1-alpha-1 plugin
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 3) Dump out the jar contents to verify that only commons-logging and the 
> web.xml were packaged, as requested
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/lib/
> WEB-INF/lib/commons-logging-1.1.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties
> 4) Now build using the 2.1-alpha-2 plugin version:
>  mvn clean install -Dwar.plugin.version=2.1-alpha-2
> 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
> this time:
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/classes/
> WEB-INF/lib/
> WEB-INF/web.xml
> WEB-INF/lib/commons-logging-1.1.jar
> WEB-INF/lib/log4j-1.2.12.jar
> WEB-INF/lib/logkit-1.0.1.jar
> WEB-INF/lib/avalon-framework-4.1.3.jar
> WEB-INF/lib/servlet-api-2.3.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties

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




[jira] Issue Comment Edited: (MWAR-182) warSourceIncludes no longer works

2009-02-15 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165710#action_165710
 ] 

Bryan Loofbourrow edited comment on MWAR-182 at 2/15/09 1:02 PM:
-

Wonderful. Thank you Dennis, I look forward to testing out the new parameter. 
Feedback below:

1) The new packagingIncludes example in the page you linked looks fine, and of 
course you are welcome to use my wording. The only thing that jars a bit (no 
pun intended) is that the use of a tag library as an example implies that it's 
a UI war, and likely you'd never get away with so short an includes list in a 
UI war. For example, here's what one of the UI wars I work with has, in 
addition to the jar includes:

{noformat}**/*.xml,**/*.properties,**/*.class,**/*.gif,**/*.png,**/*.jpg,**/*.css,**/*.js,**/*.html,**/*.tld,**/*.jsp,**/*.tag{noformat}

I'm not claiming that this matters enough to make it necessary to make a change 
in the example, just that it's worth pointing out to you.

2) Another thing I should point out about that page, although I realize that 
the connection to packingIncludes is almost tangential. That last section 
starts off  

"Now the painful part.  Your EAR project's <<>> needs to list every 
dependency that the WAR has.
 This is because Maven assumes fat WARs and does not include transitive 
dependencies
 of WARs within the EAR."

Enumerating transitive dependencies is sure painful, especially to maintain, -- 
but it's not actually necessary, if one adopts the practice I mention in the 
comments on the skinny wars page I linked above -- combining the dependencies 
that are not packaged in the war into a separate pom project, and having both 
the skinny war, and the ear, depend on them.

3) I'm wondering about how the behavior change in warSourceIncludes will 
manifest to users who are not following the discussion. Is there any way that 
users of the old will know to start using the new, such as a failing build with 
an error message, or do they have to learn the hard way, by noticing the 
behavioral changes?  I'm not worried for myself -- my organization has wised 
up, pinned all plugin versions, and invoked the "loving iron fist of Maven" to 
enforce the pinning. So we'll be reading release notes and docs when we pick up 
a new version of a plugin. But the default behavior of Maven is to go get the 
latest released version of a plugin on a regular basis, and it strikes me that 
the behaviorial change to warSourceIncludes will silently slip into most 
builds. That's what happened to us with the behavioral change to 
warSourceExcludes from 2.1-alpha-1 to 2.1-alpha-2, and which led us to enforce 
plugin version pinning. I see that warSourceIncludes is merely changing 
behavior, not going away, which lets out the possibility of failing builds when 
someone tries to use it, but it would sure be nice if there was some sort of 
indication of the change for the default Maven case. Any thoughts about this?


  was (Author: bryanloof):
Wonderful. Thank you Dennis, I look forward to testing out the new 
parameter. Feedback below:

1) The new packagingIncludes example in the page you linked looks fine, and of 
course you are welcome to use my wording. The only thing that jars a bit (no 
pun intended) is that the use of a tag library as an example implies that it's 
a UI war, and likely you'd never get away with so short an includes list in a 
UI war. For example, here's what one of the UI wars I work with has, in 
addition to the jar includes:

**/*.xml,**/*.properties,**/*.class,**/*.gif,**/*.png,**/*.jpg,**/*.css,**/*.js,**/*.html,**/*.tld,**/*.jsp,**/*.tag

I'm not claiming that this matters enough to make it necessary to make a change 
in the example, just that it's worth pointing out to you.

2) Another thing I should point out about that page, although I realize that 
the connection to packingIncludes is almost tangential. That last section 
starts off  

"Now the painful part.  Your EAR project's <<>> needs to list every 
dependency that the WAR has.
 This is because Maven assumes fat WARs and does not include transitive 
dependencies
 of WARs within the EAR."

Enumerating transitive dependencies is sure painful, especially to maintain, -- 
but it's not actually necessary, if one adopts the practice I mention in the 
comments on the skinny wars page I linked above -- combining the dependencies 
that are not packaged in the war into a separate pom project, and having both 
the skinny war, and the ear, depend on them.

3) I'm wondering about how the behavior change in warSourceIncludes will 
manifest to users who are not following the discussion. Is there any way that 
users of the old will know to start using the new, such as a failing build with 
an error message, or do they have to learn the hard way, by noticing the 
behavioral changes?  I'm not worried for myself -- my organization has w

[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-15 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165710#action_165710
 ] 

Bryan Loofbourrow commented on MWAR-182:


Wonderful. Thank you Dennis, I look forward to testing out the new parameter. 
Feedback below:

1) The new packagingIncludes example in the page you linked looks fine, and of 
course you are welcome to use my wording. The only thing that jars a bit (no 
pun intended) is that the use of a tag library as an example implies that it's 
a UI war, and likely you'd never get away with so short an includes list in a 
UI war. For example, here's what one of the UI wars I work with has, in 
addition to the jar includes:

**/*.xml,**/*.properties,**/*.class,**/*.gif,**/*.png,**/*.jpg,**/*.css,**/*.js,**/*.html,**/*.tld,**/*.jsp,**/*.tag

I'm not claiming that this matters enough to make it necessary to make a change 
in the example, just that it's worth pointing out to you.

2) Another thing I should point out about that page, although I realize that 
the connection to packingIncludes is almost tangential. That last section 
starts off  

"Now the painful part.  Your EAR project's <<>> needs to list every 
dependency that the WAR has.
 This is because Maven assumes fat WARs and does not include transitive 
dependencies
 of WARs within the EAR."

Enumerating transitive dependencies is sure painful, especially to maintain, -- 
but it's not actually necessary, if one adopts the practice I mention in the 
comments on the skinny wars page I linked above -- combining the dependencies 
that are not packaged in the war into a separate pom project, and having both 
the skinny war, and the ear, depend on them.

3) I'm wondering about how the behavior change in warSourceIncludes will 
manifest to users who are not following the discussion. Is there any way that 
users of the old will know to start using the new, such as a failing build with 
an error message, or do they have to learn the hard way, by noticing the 
behavioral changes?  I'm not worried for myself -- my organization has wised 
up, pinned all plugin versions, and invoked the "loving iron fist of Maven" to 
enforce the pinning. So we'll be reading release notes and docs when we pick up 
a new version of a plugin. But the default behavior of Maven is to go get the 
latest released version of a plugin on a regular basis, and it strikes me that 
the behaviorial change to warSourceIncludes will silently slip into most 
builds. That's what happened to us with the behavioral change to 
warSourceExcludes from 2.1-alpha-1 to 2.1-alpha-2, and which led us to enforce 
plugin version pinning. I see that warSourceIncludes is merely changing 
behavior, not going away, which lets out the possibility of failing builds when 
someone tries to use it, but it would sure be nice if there was some sort of 
indication of the change for the default Maven case. Any thoughts about this?


> warSourceIncludes no longer works
> -
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
>Reporter: Bryan Loofbourrow
> Attachments: pom.xml
>
>
> The  element no longer seems to work, as of 2.1-alpha-2. 
> It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
> demonstrate the problem when used as follows:
> 1) From the directory containing the pom.xml, create a web.xml, because 
> otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
>   mkdir -p src/main/webapp/WEB-INF
>   touch src/main/webapp/WEB-INF/web.xml
> 2) Build with the 2.1-alpha-1 plugin
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 3) Dump out the jar contents to verify that only commons-logging and the 
> web.xml were packaged, as requested
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/lib/
> WEB-INF/lib/commons-logging-1.1.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties
> 4) Now build using the 2.1-alpha-2 plugin version:
>  mvn clean install -Dwar.plugin.version=2.1-alpha-2
> 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
> this time:
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/classes/
> WEB-INF/lib/
> WEB-INF/web.xml
> WEB-INF/lib/commons-logging-1.1.jar
> WEB-INF/lib/log4j-1.2.12.jar
> WEB-INF/lib/logkit-1.0.1.jar
> WEB-INF/lib/avalon-framework-4.1.3.jar
> WEB-INF/lib/servlet-api-2.3.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/exa

[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-12 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165306#action_165306
 ] 

Bryan Loofbourrow commented on MWAR-182:


Not only do I need it, I am using it in a large, multimodule project, and it is 
hard to know what would substitute for it. Not packagingExcludes. My need is to 
package a small, but nonempty, subset of the jars into the war. That's hard to 
do well, and impossible to do in a stable manner, using a specification that 
can only tell what to exclude.

The need to package a small, but nonempty, subset of jars into a war, comes 
from the longstanding "skinny war problem" ( 
http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem ). 
In making an ear of skinny wars, one wants to package all of the jars into the 
ear, with, in some cases, a short list of exceptions that must be packaged into 
the war in order to work properly (generally tag libraries, in my case).

There are few decent solutions to the "skinny war problem" as things stand in 
Maven. By removing this includes functionality from the war plugin, the team 
would be taking away what is, in the current state of things, by far the best 
one, in my opinion.  


> warSourceIncludes no longer works
> -
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
>Reporter: Bryan Loofbourrow
> Attachments: pom.xml
>
>
> The  element no longer seems to work, as of 2.1-alpha-2. 
> It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
> demonstrate the problem when used as follows:
> 1) From the directory containing the pom.xml, create a web.xml, because 
> otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
>   mkdir -p src/main/webapp/WEB-INF
>   touch src/main/webapp/WEB-INF/web.xml
> 2) Build with the 2.1-alpha-1 plugin
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 3) Dump out the jar contents to verify that only commons-logging and the 
> web.xml were packaged, as requested
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/lib/
> WEB-INF/lib/commons-logging-1.1.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties
> 4) Now build using the 2.1-alpha-2 plugin version:
>  mvn clean install -Dwar.plugin.version=2.1-alpha-2
> 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
> this time:
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/classes/
> WEB-INF/lib/
> WEB-INF/web.xml
> WEB-INF/lib/commons-logging-1.1.jar
> WEB-INF/lib/log4j-1.2.12.jar
> WEB-INF/lib/logkit-1.0.1.jar
> WEB-INF/lib/avalon-framework-4.1.3.jar
> WEB-INF/lib/servlet-api-2.3.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties

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




[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-03 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163800#action_163800
 ] 

Bryan Loofbourrow commented on MWAR-182:


Second correction: the text refers to "" in the first line. 
That should be ""

> warSourceIncludes no longer works
> -
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
>Reporter: Bryan Loofbourrow
> Attachments: pom.xml
>
>
> The  element no longer seems to work, as of 2.1-alpha-2. 
> It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
> demonstrate the problem when used as follows:
> 1) From the directory containing the pom.xml, create a web.xml, because 
> otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
>   mkdir -p src/main/webapp/WEB-INF
>   touch src/main/webapp/WEB-INF/web.xml
> 2) Build with the 2.1-alpha-1 plugin
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 3) Dump out the jar contents to verify that only commons-logging and the 
> web.xml were packaged, as requested
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/lib/
> WEB-INF/lib/commons-logging-1.1.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties
> 4) Now build using the 2.1-alpha-2 plugin version:
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
> this time:
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/classes/
> WEB-INF/lib/
> WEB-INF/web.xml
> WEB-INF/lib/commons-logging-1.1.jar
> WEB-INF/lib/log4j-1.2.12.jar
> WEB-INF/lib/logkit-1.0.1.jar
> WEB-INF/lib/avalon-framework-4.1.3.jar
> WEB-INF/lib/servlet-api-2.3.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties

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




[jira] Commented: (MWAR-182) warSourceIncludes no longer works

2009-02-03 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163759#action_163759
 ] 

Bryan Loofbourrow commented on MWAR-182:


Sorry, the line in step 4 should read:

mvn clean install -Dwar.plugin.version=2.1-alpha-2

Cut/paste error on my part.

> warSourceIncludes no longer works
> -
>
> Key: MWAR-182
> URL: http://jira.codehaus.org/browse/MWAR-182
> Project: Maven 2.x War Plugin
>  Issue Type: Bug
>Affects Versions: 2.1-alpha-2
> Environment: RHEL 3
>Reporter: Bryan Loofbourrow
> Attachments: pom.xml
>
>
> The  element no longer seems to work, as of 2.1-alpha-2. 
> It does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
> demonstrate the problem when used as follows:
> 1) From the directory containing the pom.xml, create a web.xml, because 
> otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
>   mkdir -p src/main/webapp/WEB-INF
>   touch src/main/webapp/WEB-INF/web.xml
> 2) Build with the 2.1-alpha-1 plugin
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 3) Dump out the jar contents to verify that only commons-logging and the 
> web.xml were packaged, as requested
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/web.xml
> WEB-INF/lib/
> WEB-INF/lib/commons-logging-1.1.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties
> 4) Now build using the 2.1-alpha-2 plugin version:
>  mvn clean install -Dwar.plugin.version=2.1-alpha-1
> 5) Dump out the jar contents and notice that warSourceIncludes was ignored 
> this time:
> [warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
> META-INF/
> META-INF/MANIFEST.MF
> WEB-INF/
> WEB-INF/classes/
> WEB-INF/lib/
> WEB-INF/web.xml
> WEB-INF/lib/commons-logging-1.1.jar
> WEB-INF/lib/log4j-1.2.12.jar
> WEB-INF/lib/logkit-1.0.1.jar
> WEB-INF/lib/avalon-framework-4.1.3.jar
> WEB-INF/lib/servlet-api-2.3.jar
> META-INF/maven/
> META-INF/maven/example/
> META-INF/maven/example/example-war/
> META-INF/maven/example/example-war/pom.xml
> META-INF/maven/example/example-war/pom.properties

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




[jira] Created: (MWAR-182) warSourceIncludes no longer works

2009-02-03 Thread Bryan Loofbourrow (JIRA)
warSourceIncludes no longer works
-

 Key: MWAR-182
 URL: http://jira.codehaus.org/browse/MWAR-182
 Project: Maven 2.x War Plugin
  Issue Type: Bug
Affects Versions: 2.1-alpha-2
 Environment: RHEL 3
Reporter: Bryan Loofbourrow
 Attachments: pom.xml

The  element no longer seems to work, as of 2.1-alpha-2. It 
does seem to work in 2.1-alpha-1. I am attaching a pom.xml file which will 
demonstrate the problem when used as follows:

1) From the directory containing the pom.xml, create a web.xml, because 
otherwise it fails (setting failsOnMissingWebXml didn't seem to do the trick):
  mkdir -p src/main/webapp/WEB-INF
  touch src/main/webapp/WEB-INF/web.xml

2) Build with the 2.1-alpha-1 plugin
 mvn clean install -Dwar.plugin.version=2.1-alpha-1

3) Dump out the jar contents to verify that only commons-logging and the 
web.xml were packaged, as requested
[warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/web.xml
WEB-INF/lib/
WEB-INF/lib/commons-logging-1.1.jar
META-INF/maven/
META-INF/maven/example/
META-INF/maven/example/example-war/
META-INF/maven/example/example-war/pom.xml
META-INF/maven/example/example-war/pom.properties

4) Now build using the 2.1-alpha-2 plugin version:
 mvn clean install -Dwar.plugin.version=2.1-alpha-1

5) Dump out the jar contents and notice that warSourceIncludes was ignored this 
time:
[warsourceexample]$ jar -tf target/example-war-0.1-SNAPSHOT.war
META-INF/
META-INF/MANIFEST.MF
WEB-INF/
WEB-INF/classes/
WEB-INF/lib/
WEB-INF/web.xml
WEB-INF/lib/commons-logging-1.1.jar
WEB-INF/lib/log4j-1.2.12.jar
WEB-INF/lib/logkit-1.0.1.jar
WEB-INF/lib/avalon-framework-4.1.3.jar
WEB-INF/lib/servlet-api-2.3.jar
META-INF/maven/
META-INF/maven/example/
META-INF/maven/example/example-war/
META-INF/maven/example/example-war/pom.xml
META-INF/maven/example/example-war/pom.properties



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




[jira] Commented: (MEAR-96) earSourceExcludes does not work for jar dependency filtering like warSourceExcludes / packagingExcludes for the maven-war-plugin

2009-02-03 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163742#action_163742
 ] 

Bryan Loofbourrow commented on MEAR-96:
---

Yep, same issue here, in version 2.3.1. Note that the earSourceExcludes value 
pasted above wouldn't exclude commons-logging, but the one in the attached 
pom.xml would. I figure that's part of what ScottH means by "munged."

I worked around the problem by specifying a bundleDir for the jar in some 
location other than the one that the container will add to its classpath. Ugly 
and wasteful, but effective.

> earSourceExcludes does not work for jar dependency filtering like 
> warSourceExcludes / packagingExcludes for the maven-war-plugin
> 
>
> Key: MEAR-96
> URL: http://jira.codehaus.org/browse/MEAR-96
> Project: Maven 2.x Ear Plugin
>  Issue Type: Bug
> Environment: Windows XP SP3
>Reporter: Scott Heaberlin
> Attachments: pom.xml
>
>
> The earSourceExcludes parameter of the EarMojo does not appear to have any 
> effect on jar dependencies.  Given the pom below, commons-logging.jar should 
> be excluded from the resultant .ear archive but is not.
> The junit test for the ear mojo (test-project-014) uses earSourceExcludes but 
> only with files that are in the earSourceDirectory.
> Similar functionality works for the maven-war-plugin (warSourceExcludes, 
> which was renamed to packagingExcludes) so it was a little confusing to find 
> that earSourceIncludes does not allow filtering in the same fashion.
> -- example pom.xml
> http://maven.apache.org/POM/4.0.0";
>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/maven-v4_0_0.xsd";>
>   4.0.0
>   example
>   example-ear
>   ear
>   example-ear
>   0.1-SNAPSHOT
>   
>   sample ear project demonstrating effectiveness of
>   earSourceExcludes parameter of the maven-ear-plugin
>   
> 
> 
> 
> maven-ear-plugin
> 2.3.1
> 
>   
> src/main/application
> **/commons*
> 
> 
> 
> 
>   
>   
>   org.springframework
>   spring-core
>   1.2.7
>   
>   
> 

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




[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir

2009-01-23 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162238#action_162238
 ] 

Bryan Loofbourrow commented on MEAR-85:
---

Stephane, that sounds fine, assuming that the ear plugin has a nice unambiguous 
way to know that the build is targeting JEE5. The main point for me is that I'm 
even more eager to see a solution for this now than I was last May. Thanks for 
taking this up.

> ejb-client dependencies should be placed in defaultLibBundleDir
> ---
>
> Key: MEAR-85
> URL: http://jira.codehaus.org/browse/MEAR-85
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: James Olsen
>Assignee: Stephane Nicoll
>Priority: Minor
> Fix For: 2.3.2
>
>
> ejb-client jars should be placed in the defaultLibBundleDir when specified.  
> They're just standard jar dependencies not J2EE artifacts so should be 
> treated the same as other jars.  They're currently being placed in the root 
> directory.
> A workaround is to add an ejbClientModule entry to override the bundleDir:
> 
>   
>   ...
>   ...
>   lib
>   
> 

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




[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir

2008-08-03 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144011#action_144011
 ] 

Bryan Loofbourrow commented on MEAR-85:
---

Yeah, it's a little awkward to name, isn't it? I'll put a word in for the 
"don't fear verbosity if  it's the simplest thing you can think of " approach. 
In other words, I'd just call it "ejbClientsToDefaultLibBundleDir" or similar.

> ejb-client dependencies should be placed in defaultLibBundleDir
> ---
>
> Key: MEAR-85
> URL: http://jira.codehaus.org/browse/MEAR-85
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: James Olsen
>Assignee: Stephane Nicoll
>Priority: Minor
> Fix For: 2.3.2
>
>
> ejb-client jars should be placed in the defaultLibBundleDir when specified.  
> They're just standard jar dependencies not J2EE artifacts so should be 
> treated the same as other jars.  They're currently being placed in the root 
> directory.
> A workaround is to add an ejbClientModule entry to override the bundleDir:
> 
>   
>   ...
>   ...
>   lib
>   
> 

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




[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir

2008-08-03 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143993#action_143993
 ] 

Bryan Loofbourrow commented on MEAR-85:
---

|   I could add a flag to copy ejbClient artifacts in the defaultLibBundleDir.

I'll take the liberty of replying with respect to my use case, described in my 
earlier comment, even though your question was addressed to James Olsen. 

As long as the flag applied to all ejbClient artifacts to be packaged in the 
ear, including the ones pulled in by transitive dependencies, it sounds as 
though it would fully address the use case that I have. Your proposal of a flag 
is probably better than mine of a second Dir parameter, given that there is 
probably no need to ever specify a distinct destination directory for ejbClient 
artifacts. There's merely a need to piggyback on the destination directory 
already specified. 

> ejb-client dependencies should be placed in defaultLibBundleDir
> ---
>
> Key: MEAR-85
> URL: http://jira.codehaus.org/browse/MEAR-85
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: James Olsen
>Assignee: Stephane Nicoll
>Priority: Minor
> Fix For: 2.3.2
>
>
> ejb-client jars should be placed in the defaultLibBundleDir when specified.  
> They're just standard jar dependencies not J2EE artifacts so should be 
> treated the same as other jars.  They're currently being placed in the root 
> directory.
> A workaround is to add an ejbClientModule entry to override the bundleDir:
> 
>   
>   ...
>   ...
>   lib
>   
> 

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




[jira] Issue Comment Edited: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir

2008-05-02 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133344#action_133344
 ] 

bryanloof edited comment on MEAR-85 at 5/2/08 10:38 AM:


The situation I have, simplified,  looks like this:

ear-project DEPENDS ON 
  jar-project DEPENDS ON 
ejb-project-1-client DEPENDS ON 
   ejb-project-2-client

In the ear project, jars are supposed to go into APP-INF/lib. I use 
, and it works for most things, but not ejb-client 
dependencues.  Apparently, the maven-ear-plugin takes any dependency specified 
with a classifier of ejb-client, and puts it into the root ot the ear, unless 
you tell it to do otherwise, for a specific artifact. This behavior contrasts 
with the usual jar-packaging behavior, in that defaultLibBundleDir permits 
specifying a default location for jars in general. 

As James Olsen says, specifying the jar-project's dependency as client instead 
of ejb-client evades the maven-ear-plugin's classification of the dependency as 
an ejb client, and therefore permits it to be packaged where 
defaultLibBundleDir says it should. That's all very fine for the jar-project 
DEPENDS ON ejb-project-1 case above. But what about the transitive dependency 
in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may 
or may not control that dependency, and to the extent that I do not, what are 
my options?

If the only option at that point is to explicitly list all of the ejb-client 
artifacts on which I transitively depend, in the pom of every ear I build from 
jars that depend on clients with such transitive dependencies, then I suggest 
that this issue may be of greater import than its present classification of  
"Minor/Improvement." Forcing projects to violate the hiding of transitive Maven 
dependencies seems reasonably serious.

Also, I've had a look in the maven-ear-plugin code, and it seems very easy to 
fix, at least if you agree with me about the right way to address it. Given 
that there's a defaultLibBundleDir for specifying the default location of jar 
files, and given that someone seems to have found a reason for putting ejb 
client jars somewhere else regardless of this setting, why not add a 
defaultEjbClientBundleDir parameter?  It looks to me as though the code change 
would be nearly trivial. There's even already a parameter for passing on a 
default packaging location, in constructing the object representing the 
ejb-client. It's just that it's always set to null at present.


  was (Author: bryanloof):
The situation I have, simplified,  looks like this:

ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS 
ON ejb-project-2-client

In the ear project, jars are supposed to go into APP-INF/lib. I use 
, and it works for most things, but not ejb-client 
dependencues.  Apparently, the maven-ear-plugin takes any dependency specified 
with a classifier of ejb-client, and puts it into the root ot the ear, unless 
you tell it to do otherwise, for a specific artifact. This behavior contrasts 
with the usual jar-packaging behavior, in that defaultLibBundleDir permits 
specifying a default location for jars in general. 

As James Olsen says, specifying the jar-project's dependency as client instead 
of ejb-client evades the maven-ear-plugin's classification of the dependency as 
an ejb client, and therefore permits it to be packaged where 
defaultLibBundleDir says it should. That's all very fine for the jar-project 
DEPENDS ON ejb-project-1 case above. But what about the transitive dependency 
in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may 
or may not control that dependency, and to the extent that I do not, what are 
my options?

If the only option at that point is to explicitly list all of the ejb-client 
artifacts on which I transitively depend, in the pom of every ear I build from 
jars that depend on clients with such transitive dependencies, then I suggest 
that this issue may be of greater import than its present classification of  
"Minor/Improvement." Forcing projects to violate the hiding of transitive Maven 
dependencies seems reasonably serious.

Also, I've had a look in the maven-ear-plugin code, and it seems very easy to 
fix, at least if you agree with me about the right way to address it. Given 
that there's a defaultLibBundleDir for specifying the default location of jar 
files, and given that someone seems to have found a reason for putting ejb 
client jars somewhere else regardless of this setting, why not add a 
defaultEjbClientBundleDir parameter?  It looks to me as though the code change 
would be nearly trivial. There's even already a parameter for passing on a 
default packaging location, in constructing the object representing the 
ejb-client. It's just that it's always set to null at present.

  
> ejb-client dependencies should be placed in def

[jira] Commented: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir

2008-05-02 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133344#action_133344
 ] 

Bryan Loofbourrow commented on MEAR-85:
---

The situation I have, simplified,  looks like this:

ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS 
ON ejb-project-2-client

In the ear project, jars are supposed to go into APP-INF/lib. I use 
, and it works for most things, but not ejb-client 
dependencues.  Apparently, the maven-ear-plugin takes any dependency specified 
with a classifier of ejb-client, and puts it into the root ot the ear, unless 
you tell it to do otherwise, for a specific artifact. This behavior contrasts 
with the usual jar-packaging behavior, in that defaultLibBundleDir permits 
specifying a default location for jars in general. 

As James Olsen says, specifying the jar-project's dependency as client instead 
of ejb-client evades the maven-ear-plugin's classification of the dependency as 
an ejb client, and therefore permits it to be packaged where 
defaultLibBundleDir says it should. That's all very fine for the jar-project 
DEPENDS ON ejb-project-1 case above. But what about the transitive dependency 
in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may 
or may not control that dependency, and to the extent that I do not, what are 
my options?

If the only option at that point is to explicitly list all of the ejb-client 
artifacts on which I transitively depend, in the pom of every ear I build from 
jars that depend on clients with such transitive dependencies, then I suggest 
that this issue may be of greater import than its present classification of  
"Minor/Improvement." Forcing projects to violate the hiding of transitive Maven 
dependencies seems reasonably serious.

Also, I've had a look in the maven-ear-plugin code, and it seems very easy to 
fix, at least if you agree with me about the right way to address it. Given 
that there's a defaultLibBundleDir for specifying the default location of jar 
files, and given that someone seems to have found a reason for putting ejb 
client jars somewhere else regardless of this setting, why not add a 
defaultEjbClientBundleDir parameter?  It looks to me as though the code change 
would be nearly trivial. There's even already a parameter for passing on a 
default packaging location, in constructing the object representing the 
ejb-client. It's just that it's always set to null at present.


> ejb-client dependencies should be placed in defaultLibBundleDir
> ---
>
> Key: MEAR-85
> URL: http://jira.codehaus.org/browse/MEAR-85
> Project: Maven 2.x Ear Plugin
>  Issue Type: Improvement
>Affects Versions: 2.3.1
>Reporter: James Olsen
>Priority: Minor
>
> ejb-client jars should be placed in the defaultLibBundleDir when specified.  
> They're just standard jar dependencies not J2EE artifacts so should be 
> treated the same as other jars.  They're currently being placed in the root 
> directory.
> A workaround is to add an ejbClientModule entry to override the bundleDir:
> 
>   
>   ...
>   ...
>   lib
>   
> 

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




[jira] Commented: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error

2007-04-26 Thread Bryan Loofbourrow (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94291
 ] 

Bryan Loofbourrow commented on MSITE-211:
-

Same problem here with 2.0-beta-5; 2.0-beta-4 works fine.

> Can't deploy site using site:deploy due to a ProxyHTTP error
> 
>
> Key: MSITE-211
> URL: http://jira.codehaus.org/browse/MSITE-211
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: linux ubuntu dapper drake
>Reporter: Elid OR
>Priority: Blocker
>
> When I execute the site deployment (with version that comes with maven 2.0.5) 
> "mvn site:deploy " I got an error see log en debug mode below. This used to 
> work correctly with maven version 2.04 (so maybe site plugin version 
> 2.0-beta-4 :
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error uploading site
> Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy 
> error: Forbidden
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> 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:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> 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:324)
> 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)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading 
> site
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.wagon.authentication.AuthenticationException: 
> Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: 
> Forbidden
> at 
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186)
> at 
> org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149)
> ... 18 more
> Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: 
> proxy error: Forbidden
> at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source)
> at com.jcraft.jsch.Session.connect(Unknown Source)
> at com.jcraft.jsch.Session.connect(Unknown Source)
> at 
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158)
> ... 20 more
> [INFO] 
> 
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007
> [INFO] Final Memory: 3M/7M
> [INFO] 
> 

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




[jira] Created: (MWAR-81) Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?)

2006-10-24 Thread Bryan Loofbourrow (JIRA)
Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes 
functionality (regular expressions?)


 Key: MWAR-81
 URL: http://jira.codehaus.org/browse/MWAR-81
 Project: Maven 2.x War Plugin
  Issue Type: Wish
 Environment: n/a
Reporter: Bryan Loofbourrow
Priority: Minor


The Maven War Plugin currently permits choosing what files will wind up in the 
.war. It does this via two parameters, warSourceIncludes, and 
warSourceExcludes.  The rule appears to be that the includes are computed, and 
a list of matches made, then that list is run against the excludes, and any 
matches taken out of the include list.

The only wildcards that appear to be supported are *, **, and ?.

That doesn't work well if you are packaging wars in ears, and therefore want to 
exclude all jars from the war, except for one or two that have to be in the war 
in order to run properly.  "Exclude all but foo.jar and bar.jar" just doesn't 
translate well to "here's your simple include template, here's your simple 
exclude template" representation, at least with current wildcards.

So this is a wish specifically for something to address the "exclude all but x, 
y, and z" need for war source includes/excludes, and a suggestion that it might 
be best to deprecate the warSourceIncludes/warSourceExcludes approach in favor 
of a single parameter that supports regular expressions instead.


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




[jira] Commented: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR

2006-10-23 Thread Bryan Loofbourrow (JIRA)
[ http://jira.codehaus.org/browse/MWAR-9?page=comments#action_78249 ] 

Bryan Loofbourrow commented on MWAR-9:
--

I agree that adding an ear scope seems like the most straightforward from a 
user point of view. Philosophically, it's like a variation on provided, but 
meaning "provided in the ear."  

I also agree with those who say that supporting a mixture of in-war and in-ear 
jars is essential. Some jars have to be in the war. Examples: either jstl or 
standard tag library jars (haven't narrowed it down to discover which) must be 
in the war, it appears. The same appears to apply to myfaces. Perhaps a 
consequence of loading resources with a path instead of classpath.

> WAR plugin should support minimal WARs for inclusion within an EAR
> --
>
> Key: MWAR-9
> URL: http://jira.codehaus.org/browse/MWAR-9
> Project: Maven 2.x War Plugin
>  Issue Type: Improvement
>Reporter: Mike Perham
>
> I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my 
> deps.  This is fine for a default but maven should also support "skeleton" 
> WARs which will be packaged within an EAR.  We have EARs which package 3-4 
> WARs each and to have the deps duplicated within each WAR means we cannot 
> have shared data (since the classes are loaded within each WAR's classloader, 
> rather than by the parent EAR's classloader).  It also means 80MB EARs!  :-)
> It seems like two things need to happen:
> 1) Add a "skeleton" flag which prevents copying any dependencies to 
> WEB-INF/lib.
> 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which 
> lists the relative locations of the dependencies within the parent EAR.
> Fabrice has basically the same idea written down here.  Starting with "- for 
> a War..." : 
> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2

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