[jira] Commented: (MAVEN-1474) exceptions writing classes that use DOM

2004-10-20 Thread jira 
The following comment has been added to this issue:

 Author: Brett Porter
Created: Wed, 20 Oct 2004 7:38 PM
   Body:
This is probably because Maven is endorsing other xml libraries, but those are not in 
the compilation classpath so you miss out on both fronts.

Does setting
maven.compile.fork=true

help?

-
View this comment:
  http://jira.codehaus.org/browse/MAVEN-1474?page=comments#action_25632

-
View the issue:
  http://jira.codehaus.org/browse/MAVEN-1474

Here is an overview of the issue:
-
Key: MAVEN-1474
Summary: exceptions writing classes that use DOM
   Type: Bug

 Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven
   Versions:
 1.0

   Assignee: 
   Reporter: Malachi de AElfweald

Created: Wed, 20 Oct 2004 5:12 PM
Updated: Wed, 20 Oct 2004 7:38 PM
Environment: WinXPSP2, JDK/J2SE 1.5/5.0

Description:
When compiling without Maven, everything works fine.

When compiling with Maven, it says that getTextContent and setTextContent (DOM) are 
not found.

maven.compile.source=1.5
maven.compile.target=1.5


java:compile:
[echo] Compiling to E:\devel\excp/target/classes
[javac] Compiling 13 source files to E:\devel\excp\target\classes
E:\devel\excp\src\java\org\eoti\tools\excp\cfg\DOMWrapper.java:108: cannot find symbol
symbol  : method setTextContent(java.lang.String)
location: interface org.w3c.dom.Element
cp.setTextContent(url.toExternalForm());
  ^
E:\devel\excp\src\java\org\eoti\tools\excp\cfg\EXCPDomNode.java:57: cannot find symbol
symbol  : method getTextContent()
location: interface org.w3c.dom.Node
public String getText(){return node.getTextContent().trim();}
   ^
2 errors

BUILD FAILED


-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVENUPLOAD-239) Ashkay Upload Request

2004-10-20 Thread jira 
Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://jira.codehaus.org/browse/MAVENUPLOAD-239

Here is an overview of the issue:
-
Key: MAVENUPLOAD-239
Summary: Ashkay Upload Request
   Type: Task

 Status: Unassigned

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven-upload-requests

   Assignee: 
   Reporter: Dave Brown

Created: Wed, 20 Oct 2004 7:19 PM
Updated: Wed, 20 Oct 2004 7:19 PM

Description:
http://ashkay.sourceforge.net/downloads/ashkay-1.0-bundle.jar
http://ashkay.sourceforge.net
http://ashkay.sourceforge.net/team-list.html



-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (MAVENUPLOAD-238) Please upload Dumbster

2004-10-20 Thread jira 
Message:

   The following issue has been closed.

   Resolver: Emmanuel Venisse
   Date: Wed, 20 Oct 2004 5:19 PM

Done. We can purpose to jason kitchen to create a synchronisable directory with 
ibiblio.
-
View the issue:
  http://jira.codehaus.org/browse/MAVENUPLOAD-238

Here is an overview of the issue:
-
Key: MAVENUPLOAD-238
Summary: Please upload Dumbster
   Type: Task

 Status: Closed
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven-upload-requests

   Assignee: 
   Reporter: David Eric Pugh

Created: Wed, 20 Oct 2004 2:14 PM
Updated: Wed, 20 Oct 2004 5:19 PM

Description:
http://www.opensourceconnections.com/dumbster-1.0.3-bundle.jar

This tool can be found at http://quintanasoft.com/dumbster/.  It allows testing of 
email software without requiring an SMTP server.

Currently it is only available in source.


-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVEN-1474) exceptions writing classes that use DOM

2004-10-20 Thread jira 
Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://jira.codehaus.org/browse/MAVEN-1474

Here is an overview of the issue:
-
Key: MAVEN-1474
Summary: exceptions writing classes that use DOM
   Type: Bug

 Status: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven
   Versions:
 1.0

   Assignee: 
   Reporter: Malachi de AElfweald

Created: Wed, 20 Oct 2004 5:12 PM
Updated: Wed, 20 Oct 2004 5:12 PM
Environment: WinXPSP2, JDK/J2SE 1.5/5.0

Description:
When compiling without Maven, everything works fine.

When compiling with Maven, it says that getTextContent and setTextContent (DOM) are 
not found.

maven.compile.source=1.5
maven.compile.target=1.5


java:compile:
[echo] Compiling to E:\devel\excp/target/classes
[javac] Compiling 13 source files to E:\devel\excp\target\classes
E:\devel\excp\src\java\org\eoti\tools\excp\cfg\DOMWrapper.java:108: cannot find symbol
symbol  : method setTextContent(java.lang.String)
location: interface org.w3c.dom.Element
cp.setTextContent(url.toExternalForm());
  ^
E:\devel\excp\src\java\org\eoti\tools\excp\cfg\EXCPDomNode.java:57: cannot find symbol
symbol  : method getTextContent()
location: interface org.w3c.dom.Node
public String getText(){return node.getTextContent().trim();}
   ^
2 errors

BUILD FAILED


-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: can't create an issue on jira

2004-10-20 Thread Arnaud HERITIER 
Your permissions seems ok :-(
You are in jira-users group and jira-users can create issues on maven !

Arnaud

> -Message d'origine-
> De : Julien Kirch [mailto:[EMAIL PROTECTED]
> Envoyé : mercredi 20 octobre 2004 22:06
> À : Maven Developers List
> Objet : Re: can't create an issue on jira
> 
> Trygve Laugstl wrote:
> 
> >You have to be logged in to make a new issue.
> >
> >
> 
> 
> the question was :
> " I'm logged in jira and the issue creation option is disabled (in the
> project maven and all the plugin I tried), is it normal ?"
> 
> but nice try
> 
> and thanks
> 
> Julien
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> #== gPopper Menu ===#
> Delete from Gmail inbox:   mailto:del|[EMAIL PROTECTED]
> Mark message as unread:mailto:unr|[EMAIL PROTECTED]
> Mark message as read:  mailto:rea|[EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: can't create an issue on jira

2004-10-20 Thread Arnaud HERITIER 
Actually I have an error :-(

If I can access to it, I'll check your rights.

Arnaud


System Error
A system error has occurred. 

If this problem persists - please notify your JIRA administrator of this problem. 

If you are an administrator, please try submitting this problem via the Support 
Request Page. 

If you experience problems getting to this support page, please send an email to 
[EMAIL PROTECTED] with the following
information: 

a description of your problem 
cut & paste the error and system information found below 
attach the application server log file 

Cause:


java.lang.IllegalArgumentException: [GenericEntity.set] "scheme" is not a field of 
SchemePermissionsat
org.ofbiz.core.entity.GenericEntity.set(GenericEntity.java:198) at
org.ofbiz.core.entity.GenericEntity.setFields(GenericEntity.java:524)   at
org.ofbiz.core.entity.GenericEntity.(GenericEntity.java:98)   at
org.ofbiz.core.entity.GenericValue.(GenericValue.java:63) at
org.ofbiz.core.entity.GenericDelegator.findByAnd(GenericDelegator.java:765) at
org.ofbiz.core.entity.GenericDelegator.getRelated(GenericDelegator.java:1205)   at
org.ofbiz.core.entity.GenericDelegator.getRelated(GenericDelegator.java:1151)   at
org.ofbiz.core.entity.GenericValue.getRelated(GenericValue.java:116)at
com.atlassian.jira.scheme.AbstractSchemeManager.getEntities(AbstractSchemeManager.java:134)
 at
com.atlassian.jira.permission.DefaultPermissionSchemeManager.cacheSchemeEntities(DefaultPermissionSchemeManager.java:320)
   at
com.atlassian.jira.permission.DefaultPermissionSchemeManager.getEntities(DefaultPermissionSchemeManager.java:174)
   at
com.atlassian.jira.permission.DefaultPermissionSchemeManager.getEntities(DefaultPermissionSchemeManager.java:72)
at
com.atlassian.jira.permission.DefaultPermissionSchemeManager.hasSchemePermission(DefaultPermissionSchemeManager.java:293)
   at
com.atlassian.jira.permission.DefaultPermissionSchemeManager.hasPermission(DefaultPermissionSchemeManager.java:278)
 at
com.atlassian.jira.permission.DefaultPermissionSchemeManager.hasSchemeAuthority(DefaultPermissionSchemeManager.java:232)
at
com.atlassian.jira.security.AbstractPermissionManager.hasProjectPermission(AbstractPermissionManager.java:154)
  at
com.atlassian.jira.security.AbstractPermissionManager.hasPermission(AbstractPermissionManager.java:104)
 at
/decorators/main.jsp._jspService(/decorators/main.jsp.java:477) (JSP page line 32) 
 at com.orionserver[Orion/2.0.2 (build
11157)].http.OrionHttpJspPage.service(.:70) at com.evermind[Orion/2.0.2 (build 
11157)]._ay._rkb(.:5741) at
com.evermind[Orion/2.0.2 (build 11157)].server.http.JSPServlet.service(.:31)at 
com.evermind[Orion/2.0.2 (build
11157)]._hb.doFilter(.:59)  at 
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:46)  at
com.evermind[Orion/2.0.2 (build 11157)]._ha.doFilter(.:16)  at
com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:84) at 
com.evermind[Orion/2.0.2 (build
11157)]._ha.doFilter(.:20)  at 
com.atlassian.seraph.filter.LoginFilter.doFilter(LoginFilter.java:95)at
com.evermind[Orion/2.0.2 (build 11157)]._ha.doFilter(.:20)  at
com.atlassian.util.profiling.filters.ProfilingFilter.doFilter(ProfilingFilter.java:132)
 at com.evermind[Orion/2.0.2 (build
11157)]._ha.doFilter(.:20)  at
com.atlassian.jira.web.filters.ActionCleanupDelayFilter.doFilter(ActionCleanupDelayFilter.java:29)
  at com.evermind[Orion/2.0.2
(build 11157)]._ha.doFilter(.:20)   at 
com.atlassian.johnson.filters.JohnsonFilter.doFilter(JohnsonFilter.java:50)  at
com.evermind[Orion/2.0.2 (build 11157)]._ha.doFilter(.:20)  at
com.atlassian.jira.web.filters.gzip.GzipFilter.doFilter(GzipFilter.java:60) at 
com.evermind[Orion/2.0.2 (build
11157)]._ha.doFilter(.:20)  at 
com.atlassian.core.filters.AbstractEncodingFilter.doFilter(AbstractEncodingFilter.java:38)
   at
com.evermind[Orion/2.0.2 (build 11157)]._cub._pod(.:383)at 
com.evermind[Orion/2.0.2 (build 11157)]._cub.include(.:90)   at
com.opensymphony.module.sitemesh.filter.PageFilter.applyDecorator(PageFilter.java:169) 
 at
com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:68) at
com.atlassian.jira.web.filters.SitemeshExcludePathFilter.doFilter(SitemeshExcludePathFilter.java:36)
at com.evermind[Orion/2.0.2
(build 11157)]._ha.doFilter(.:16)   at 
com.atlassian.seraph.filter.SecurityFilter.doFilter(SecurityFilter.java:164) at
com.evermind[Orion/2.0.2 (build 11157)]._ha.doFilter(.:20)  at
com.atlassian.seraph.filter.LoginFilter.doFilter(LoginFilter.java:181)  at 
com.evermind[Orion/2.0.2 (build
11157)]._ha.doFilter(.:20)  at 
com.atlassian.util.profiling.filters.ProfilingFilter.doFilter(ProfilingFilter.java:132)
  at
com.evermind[Orion/2.0.2 (build 11157)]._ha.doFilter(.:20)  at
com.atlassian.jira.web.filters.ActionCleanupDelayFilter.doFilter(ActionCleanupDelayFilter.java:37)

Re: can't create an issue on jira

2004-10-20 Thread Julien Kirch 
Trygve Laugstøl wrote:
You have to be logged in to make a new issue.
 


the question was :
" I'm logged in jira and the issue creation option is disabled (in the 
project maven and all the plugin I tried), is it normal ?"

but nice try
and thanks
Julien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: can't create an issue on jira

2004-10-20 Thread Trygve Laugstøl 
On Wed, Oct 20, 2004 at 09:57:46PM +0200, Julien Kirch wrote:
> Arnaud HERITIER wrote:
> 
> >Hi Julien
> >
> >It seems to work for me.
> >
> >http://jira.codehaus.org/secure/CreateIssue!default.jspa
> >
> >There was certainly a problem. It happens from time to time.
> >
> >Arnaud
> > 
> >
> 
> I still haven't the link on the projects (tried regulary all day long), 
> and when directly trying your link
> 
> "*Step 1 of 2*: Choose the project and issue type...
> 
> You do not have the permissions required to browse any projects."

You have to be logged in to make a new issue.

--
Trygve

> 
> Julien
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


signature.asc
Description: Digital signature

Re: can't create an issue on jira

2004-10-20 Thread Julien Kirch 
Arnaud HERITIER wrote:
Hi Julien
It seems to work for me.
http://jira.codehaus.org/secure/CreateIssue!default.jspa
There was certainly a problem. It happens from time to time.
Arnaud
 

I still haven't the link on the projects (tried regulary all day long), 
and when directly trying your link

"*Step 1 of 2*: Choose the project and issue type...
You do not have the permissions required to browse any projects."
Julien
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: maven-plugins/eclipse/src/plugin-test maven.xml

2004-10-20 Thread epugh 
epugh   2004/10/20 11:23:11

  Modified:eclipse  plugin.properties
   eclipse/src/plugin-resources/templates classpath.jelly
   eclipse/src/plugin-test maven.xml
  Log:
  Remove temporary property.  Issue with add resources resolved by discussion on 
mailing list.
  
  Revision  ChangesPath
  1.8   +0 -1  maven-plugins/eclipse/plugin.properties
  
  Index: plugin.properties
  ===
  RCS file: /home/cvs/maven-plugins/eclipse/plugin.properties,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- plugin.properties 19 Oct 2004 14:13:04 -  1.7
  +++ plugin.properties 20 Oct 2004 18:23:11 -  1.8
  @@ -26,4 +26,3 @@
   maven.eclipse.goals = plugins
   maven.gen.src=${maven.build.dir}/generated-sources
   maven.eclipse.src.extension = zip
  -maven.eclipse.addResources=false
  
  
  
  1.29  +0 -6  
maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly
  
  Index: classpath.jelly
  ===
  RCS file: 
/home/cvs/maven-plugins/eclipse/src/plugin-resources/templates/classpath.jelly,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- classpath.jelly   19 Oct 2004 14:13:04 -  1.28
  +++ classpath.jelly   20 Oct 2004 18:23:11 -  1.29
  @@ -57,8 +57,6 @@
   
   
   
  -
  -
 
   
   
  @@ -75,7 +73,6 @@
   
 
   
  -
 
   
 
  @@ -138,8 +135,6 @@
   
   
 
  -  
  -  
   
 
 
  @@ -155,7 +150,6 @@
   
   
   
  -  
 
   
 
  
  
  
  1.17  +3 -19 maven-plugins/eclipse/src/plugin-test/maven.xml
  
  Index: maven.xml
  ===
  RCS file: /home/cvs/maven-plugins/eclipse/src/plugin-test/maven.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- maven.xml 19 Oct 2004 14:13:04 -  1.16
  +++ maven.xml 20 Oct 2004 18:23:11 -  1.17
  @@ -20,7 +20,7 @@
xmlns:u="jelly:util"
xmlns:x="jelly:xml">
   
  -  
  +  
 
 
 
  @@ -111,7 +111,7 @@
   
   
   
  -  
  +  
   
 
 
  @@ -153,22 +153,6 @@
   
   

  -
  -  
  -  
  - 
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -
  -  
  -
  -
  + 
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (MPECLIPSE-48) handling source attachments (patch)

2004-10-20 Thread jira 
Message:

   The following issue has been closed.

   Resolver: David Eric Pugh
   Date: Wed, 20 Oct 2004 2:21 PM

Discussion on mailing list resolved my last concern.
-
View the issue:
  http://jira.codehaus.org/browse/MPECLIPSE-48

Here is an overview of the issue:
-
Key: MPECLIPSE-48
Summary: handling source attachments (patch)
   Type: Improvement

 Status: Closed
   Priority: Major
 Resolution: FIXED

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven-eclipse-plugin
   Fix Fors:
 1.9
   Versions:
 1.9

   Assignee: David Eric Pugh
   Reporter: fabrizio giustina

Created: Tue, 12 Oct 2004 4:36 PM
Updated: Wed, 20 Oct 2004 2:21 PM

Description:
Actually maven repository doesn't contain source artifacts, however it would be nice 
if eclipse users could have a way to handle source for jars and have them added to 
eclipse .classpath (needed for debug and javadocs).

The attached path let users store sources in the local maven repository in the same 
way other artifacts are managed. Through the modification of the jar path the plugin 
will look for the sources file and, if existing, it will add them to the .classpath 
file.

The position of src files is controlled by 2 plugin properties: maven.eclipse.src.dir 
(directory for source artifact type) and maven.eclipse.src.extension (extension for 
files). These are temporarely managed as eclipse plugin properties till there is a 
standard maven default for them.

As an example, using the default values for these properties:
MAVEN_REPO/eclipse/jars/eclipse-ui-3.0.0.jar
will be mapped to
MAVEN_REPO/eclipse/src/eclipse-ui-3.0.0.zip

If the source zip is not available, it will not be added to the classpath file, so it 
will not cause any problem to users who don't have sources in their local repository.




-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MAVENUPLOAD-238) Please upload Dumbster

2004-10-20 Thread jira 
Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://jira.codehaus.org/browse/MAVENUPLOAD-238

Here is an overview of the issue:
-
Key: MAVENUPLOAD-238
Summary: Please upload Dumbster
   Type: Task

 Status: Unassigned

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven-upload-requests

   Assignee: 
   Reporter: David Eric Pugh

Created: Wed, 20 Oct 2004 2:14 PM
Updated: Wed, 20 Oct 2004 2:14 PM

Description:
http://www.opensourceconnections.com/dumbster-1.0.3-bundle.jar

This tool can be found at http://quintanasoft.com/dumbster/.  It allows testing of 
email software without requiring an SMTP server.

Currently it is only available in source.


-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [eclipse] Need to rethink using pom.build.resources in .classpath for Eclipse Plugin

2004-10-20 Thread Eric Pugh 
Well..  I think everybodies points are well said!  I learn something new
about doing project layout.  In retrospect, my setup is kinda boneheaded,
thats why I didn't see it when committing patches..  Only when I started
using it.  And instead of taking the simple approach of rationalizing my
layout, I started thinking about redesigning the plugin around it!

I will yank out the OFF switch!

Eric

> -Original Message-
> From: Fabrizio Giustina [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 19, 2004 10:09 PM
> To: Maven Developers List
> Subject: Re: [eclipse] Need to rethink using pom.build.resources in
> .classpath for Eclipse Plugin
>
>
> I also think that having a single directory for both "standard" and
> "test" resources is pretty unusual and should be discouraged...
>
> a common project layout is usually something like:
> src/
>   main
>   resources
>   test
>   test-resources
>
> said that, I would like to see the include resource property ON by
> default also for the following considerations:
>
> - loosing source resources will break probably more builds than having
> resource folders added twice for projects with such unusual directory
> layout: if resource directories are missed users will not be aware but
> they will probably not be able to run unit tests at all in eclipse.
>
> - also with your suggested fix _there is no way_ in eclipse to handle
> a similar situation: you can avoid adding a resource directory twice,
> but you will never be able to have files in the same resource
> directory that go into two different target directory. For example you
> can't have all your *.properties files in src/conf to go to
> target/classes and all the test*.properties files go to
> target/test-classes. Eclipse simply doesn't allow the same source
> directory to be added twice, regardless of filters and target
> directoryies.
>
> I would prefer having the properties enabled by default, documenting
> this "eclipse limit" in plugin site and leaving to users the choice to
> setting the project property off or fixing their directory layout...
>
>
> fabrizio
>
>
>
>
>
>
> On Wed, 20 Oct 2004 06:48:20 +1000, Brett Porter <[EMAIL PROTECTED]> wrote:
> > There is no way the test resources should be in src/conf. It should be
> > discouraged (although not broken :)
> >
> > That said, I think the current fix is correct.
> >
> > - Brett
> >
> >
> >
> > Eric Pugh wrote:
> >
> > >Hi all,
> > >
> > >A while ago some patches where made that allowed the
>  elements
> > >to be added to the Eclipse .classpath.  This looked good, and
> I committed
> > >it.  However, as I have gone on with more testing, I think
> this needs to be
> > >reworked.
> > >
> > >What happens is right now the resources for the regular java
> files and in
> > >the  section are duplicated...  This can lead to a
> situation where
> > >you import the same path twice.  For example, in the below (trimmed)
> > >section, I want to copy some resources always, and a
> log4j.properties when
> > >running unit tests:
> > >
> > >
> > >
> > >
> > >
> > >src/conf
> > >/
> > >
> > >test.avalonconf.xml
> > >
> > >false
> > >
> > >
> > >
> > >log4j.properties
> > >
> > >false
> > >
> > >
> > >
> > >
> > >
> > >src/conf
> > >/
> > >
> > >hibernate.hbm.xml
> > >ehcache.xml
> > >
> > >false
> > >
> > >
> > >
> > >
> > >However, because they both go from src/conf to /, this causes
> two records to
> > >be created in Eclipse.  I think, what needs to done is that a
> map of all the
> > >possible sources needs to be made, and then we aggreagate
> together all the
> > >changes.  However, this is a pretty big change, and I've not
> got the time
> > >for it right now, but I'll be happy to help.
> > >
> > >Also, we where not properly dealing with includes and excludes
> either..  I
> > >added that.
> > >
> > >Because this change can break things, I've added an extra check.  If
> > >maven.eclipse.addResources=true in your project.properties, then the
> > >existing logic will occur.  By default this is turned off so
> we don't start
> > >breaking everybodies builds.
> > >
> > >Eric Pugh
> > >
> > >
> > >
> > >
> > >
> > >-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>

Re: Is maven.final.name deprecated?

2004-10-20 Thread Brett Porter 
Yes, I meant it in terms of there being one main output. There may be 
others, but they are offshoots of the original. You can read back 
through this thread, the previous discussions, and the discussions on 
m2-dev (I think eyebrowse is still the only one archiving this 
unfortunately) for more information.

Cheers,
Brett
Dion Gillard wrote:
On Tue, 19 Oct 2004 22:32:35 +1000, Brett Porter <[EMAIL PROTECTED]> wrote:
[snip]
 

This is right - you need to know what the single build artifact is, and
that should be {maven.final.name}.jar
   

Did you really mean this? Having a jar as the only artifact is very restrictive.
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (MPXDOC-123) a way to copy xml files instead of transforming

2004-10-20 Thread jira 
Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://jira.codehaus.org/browse/MPXDOC-123

Here is an overview of the issue:
-
Key: MPXDOC-123
Summary: a way to copy xml files instead of transforming
   Type: Improvement

 Status: Open
   Priority: Minor

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

Project: maven-xdoc-plugin
   Versions:
 1.8

   Assignee: Arnaud HERITIER
   Reporter: Shinobu Kawai

Created: Wed, 20 Oct 2004 7:17 AM
Updated: Wed, 20 Oct 2004 7:17 AM
Environment: Any

Description:
Currently, there is no way to copy xml files from the xdocs directory to the docs 
directory.
cf. http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=812567

It would be great if there was a property like maven.xdoc.exclude.xml to tell xdoc 
what xml to transform and what to just copy.

A work-around would be to put the xml you want untouched outside of the xdocs 
directory and copy it on a postGoal of xdoc.


-
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is maven.final.name deprecated?

2004-10-20 Thread Felipe Leme 
On Wed, 2004-10-20 at 07:04, Dion Gillard wrote:

> Did you really mean this? Having a jar as the only artifact is very restrictive.

Exactly. I guess that's the reason the maven.war.final.name was created
at first instance.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is maven.final.name deprecated?

2004-10-20 Thread Dion Gillard 
On Tue, 19 Oct 2004 22:32:35 +1000, Brett Porter <[EMAIL PROTECTED]> wrote:
[snip]
> This is right - you need to know what the single build artifact is, and
> that should be {maven.final.name}.jar

Did you really mean this? Having a jar as the only artifact is very restrictive.

-- 
http://www.multitask.com.au/people/dion/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]