subject:"RE\: Maven Build \(Ongoing Work Thread\)"


Hello,

please apply this patch to the pom in the build directory to simplfy the 
build process.

Changes:
Added default goal
Removed tabs
Added www.atanion.com/maven2 as snapshot plugin repository
Changed list to List in mailingLists
Changed finalname to myfaces-${version}
Skipped the tests until they are stable

With this patch the xslt-plugin is fetched from the atanion maven 
repositry, you don't need to install the xslt-plugin to your local 
repository manualy. I have deployed the xslt-plugin into the atanion 
maven repository (with the patch for 
http://jira.codehaus.org/browse/MOJO-203).



Some other comments on the maven build to improve the build:

Please use as much as possible the ${version} instead of hardcoding the 
version and remove the version tag if a parent pom exists(but not in 
the parent description see tobago poms).
Please move the assembly plugin configuration in the master pom to api 
or impl otherwise every subproject try to call the assembly plugin.
Can we removed the svn externals. With the maven build they are useless 
for api, impl, commons, tomahawk, sandbox..

It would be nice if the master pom is in the root directory of myfaces.
Some plugin (idea) are not working with the current structure.

Any comments

Best Regards

Bernd



Bernd Bohmann schrieb:

Hello Sean,

I think the current version of the surefire-plugin doesn't support the 
forking mode. This is fixed in the latest not yet released version.
I see the StateUtils are using a static block for loading the 
properties. I don't know how this can work if your are in one JVM?


I think you have two options:
Disable the test until the new version of the surefire plugin is 
released or change the test to a mock version.


Any comments?

The StateUtilsAES_CBCTestCase doesn't work in my environment.
A missing dependency or wrong configuration?
I get following error:

java.security.InvalidKeyException: Illegal key size


Bernd

Sean Schofield schrieb:


Dennis,

I'm still having issues with the client state encryption tests.  Can
you find a way to make them run in Maven?

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:


Done

http://jira.codehaus.org/browse/MOJO-203

Sean Schofield schrieb:


You beat me to the patch :-)  Can you submit this to codehaus in their
JIRA so eventually it makes it into the real source code?

Regards,

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:



Hello Martin,

the xslt-maven-plugin doesn't create destDir if not exists.

Please apply the patch:

Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
===
--- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision 
1181)

+++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
@@ -116,6 +116,10 @@
{
destFileName = destFileName.replaceAll(
fileNameRegex, fileNameReplacement );
}
+   if( !destDir.exists() )
+   {
+   destDir.mkdirs();
+   }
File destFile = new File( destDir, destFileName );

if ( destFile.exists()  srcFile.lastModified() 
destFile.lastModified() )


Bernd

Martin Marinschek schrieb:


The build doesn't run on my machine anymore - ok, it runs, but the 
tld

files are not created anymore.

The tld's cannot be created, as the target/classes/META-INF directory
doesn't exist.

Solution anyone?

regards,

Martin

On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:




Devs,

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:



Changes to the TLD files don't seem to be being picked up at 
build time;



this was a problem in the Ant build as well but 'ant clean' fixed 
it there,

but 'mvn clean' doesn't here.




My situation:  I editied



tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml 

and ran 'mvn install'.  My changes didn't take, so I did a 'mvn 
clean' then

a 'mvn install'.  Changes still aren't picked up.




I suspect it's the cached intermediate file at



tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem.  It isn't deleted by a clean.




[INFO]



 






[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]



 






[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:



C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld 




All generated files should live in the target subdirectory, 
including

generated resources such as .tld files.

In ADF Faces we merge together a base .tld from
src/main/conf/META-INF/xxx-base.tld with other metadata to generate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
and the plugin automatically adds

Re: Maven Build (Ongoing Work Thread)

Thanks Bernd,

just committed the guy.

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 Hello,

 please apply this patch to the pom in the build directory to simplfy the
 build process.
 Changes:
 Added default goal
 Removed tabs
 Added www.atanion.com/maven2 as snapshot plugin repository
 Changed list to List in mailingLists
 Changed finalname to myfaces-${version}
 Skipped the tests until they are stable

 With this patch the xslt-plugin is fetched from the atanion maven
 repositry, you don't need to install the xslt-plugin to your local
 repository manualy. I have deployed the xslt-plugin into the atanion
 maven repository (with the patch for
 http://jira.codehaus.org/browse/MOJO-203).


 Some other comments on the maven build to improve the build:

 Please use as much as possible the ${version} instead of hardcoding the
 version and remove the version tag if a parent pom exists(but not in
 the parent description see tobago poms).
 Please move the assembly plugin configuration in the master pom to api
 or impl otherwise every subproject try to call the assembly plugin.
 Can we removed the svn externals. With the maven build they are useless
 for api, impl, commons, tomahawk, sandbox..
 It would be nice if the master pom is in the root directory of myfaces.
 Some plugin (idea) are not working with the current structure.

 Any comments

 Best Regards

 Bernd



 Bernd Bohmann schrieb:
  Hello Sean,
 
  I think the current version of the surefire-plugin doesn't support the
  forking mode. This is fixed in the latest not yet released version.
  I see the StateUtils are using a static block for loading the
  properties. I don't know how this can work if your are in one JVM?
 
  I think you have two options:
  Disable the test until the new version of the surefire plugin is
  released or change the test to a mock version.
 
  Any comments?
 
  The StateUtilsAES_CBCTestCase doesn't work in my environment.
  A missing dependency or wrong configuration?
  I get following error:
 
  java.security.InvalidKeyException: Illegal key size
 
 
  Bernd
 
  Sean Schofield schrieb:
 
  Dennis,
 
  I'm still having issues with the client state encryption tests.  Can
  you find a way to make them run in Maven?
 
  Sean
 
  On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 
  Done
 
  http://jira.codehaus.org/browse/MOJO-203
 
  Sean Schofield schrieb:
 
  You beat me to the patch :-)  Can you submit this to codehaus in their
  JIRA so eventually it makes it into the real source code?
 
  Regards,
 
  Sean
 
  On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 
 
  Hello Martin,
 
  the xslt-maven-plugin doesn't create destDir if not exists.
 
  Please apply the patch:
 
  Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
  ===
  --- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision
  1181)
  +++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
  @@ -116,6 +116,10 @@
  {
  destFileName = destFileName.replaceAll(
  fileNameRegex, fileNameReplacement );
  }
  +   if( !destDir.exists() )
  +   {
  +   destDir.mkdirs();
  +   }
  File destFile = new File( destDir, destFileName );
 
  if ( destFile.exists()  srcFile.lastModified() 
  destFile.lastModified() )
 
 
  Bernd
 
  Martin Marinschek schrieb:
 
 
  The build doesn't run on my machine anymore - ok, it runs, but the
  tld
  files are not created anymore.
 
  The tld's cannot be created, as the target/classes/META-INF directory
  doesn't exist.
 
  Solution anyone?
 
  regards,
 
  Martin
 
  On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:
 
 
 
  Devs,
 
  On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 
 
  Changes to the TLD files don't seem to be being picked up at
  build time;
 
 
  this was a problem in the Ant build as well but 'ant clean' fixed
  it there,
  but 'mvn clean' doesn't here.
 
 
 
  My situation:  I editied
 
 
  tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
 
  and ran 'mvn install'.  My changes didn't take, so I did a 'mvn
  clean' then
  a 'mvn install'.  Changes still aren't picked up.
 
 
 
  I suspect it's the cached intermediate file at
 
 
  tomahawk\src\main\resources\META-INF\tomahawk.tld that's
  causing the problem.  It isn't deleted by a clean.
 
 
 
  [INFO]
 
 
  
 
 
 
 
  [INFO] Building Tomahawk
  [INFO]task-segment: [install]
  [INFO]
 
 
  
 
 
 
 
  [INFO] [xslt:transform {execution: default}]
  [INFO] # of XML files: 1
  [INFO] file up-to-date:
 
 
  C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld
 
 
 
  All generated files

Re: Maven Build (Ongoing Work Thread)

 Hello Sean,

 I think the current version of the surefire-plugin doesn't support the
 forking mode. This is fixed in the latest not yet released version.
 I see the StateUtils are using a static block for loading the
 properties. I don't know how this can work if your are in one JVM?

Why does one JVM matter in this case?  Why would you need to fork? 
Aren't the unit tests run in a single JVM?

 I think you have two options:
 Disable the test until the new version of the surefire plugin is
 released or change the test to a mock version.

 Any comments?

A mock version would be my preference.  @Dennis: Care to take a stab at one?

 The StateUtilsAES_CBCTestCase doesn't work in my environment.
 A missing dependency or wrong configuration?
 I get following error:

 java.security.InvalidKeyException: Illegal key size

According to the wiki there is a java policy file that needs to be in
place.  I'm hoping Dennis (or someone else) can come up with a
workaround for testing purposes.  It's been a while since I've done
JCE and I'm pretty busy ATM.


 Bernd


Sean

Re: Maven Build (Ongoing Work Thread)

 Hello,

 please apply this patch to the pom in the build directory to simplfy the
 build process.
 Changes:
 Added default goal

Good idea

 Removed tabs

Sorry.  My fault.  I used UltraEdit instead of my IDE and the setting
weren't right.

 Added www.atanion.com/maven2 as snapshot plugin repository

OK as a temporary solution.  Eventually we should figure out the best
mechanism for hosting our plugins on myfaces.apache.org.

 Changed list to List in mailingLists

+1

 Changed finalname to myfaces-${version}

Good idea.  I assume this means the version will be inherited from the
pom?  I have been reading up on the filtering stuff as well.  I think
we can stop hard coding the versions in the example webapps and use a
message bundle with ${pom.version}.

 Skipped the tests until they are stable

OK hopefully we get those fixed soon.


 With this patch the xslt-plugin is fetched from the atanion maven
 repositry, you don't need to install the xslt-plugin to your local
 repository manualy. I have deployed the xslt-plugin into the atanion
 maven repository (with the patch for
 http://jira.codehaus.org/browse/MOJO-203).
 Some other comments on the maven build to improve the build:

 Please use as much as possible the ${version} instead of hardcoding the
 version and remove the version tag if a parent pom exists(but not in
 the parent description see tobago poms).

So 1.1.2 is defined in only the parent POM?  What if you want to build
tomahawk by itself (without the parent pom?)

I think this is a tricky problem.  Also, if we ever release different
version numbers for the subprojects won't this cause a problem?

 Please move the assembly plugin configuration in the master pom to api
 or impl otherwise every subproject try to call the assembly plugin.

Maybe we could have a special module called 'deploy'?  That would have
the nightly build, assembly and release stuff in it?  I think that
might be better then picking an arbitrary module like api.  What do
you think?

 Can we removed the svn externals. With the maven build they are useless
 for api, impl, commons, tomahawk, sandbox..

What do you mean useless?  We did get rid of the externals for the
build dir which used to be in every subproject.  The only externals
now are for current and a few for the TLD entities.

I'm +1 for getting rid of them if we can do the same thing a different
way.  But I think having the current external is good and its
becoming a psuedo-standard.  Other projects (including) Struts adopt
the same approach and its nice to have.

Keep in mind under each subproject we have trunk, branches and tags. 
Without an external you would get the entire repository if you checked
out the top level!  That would definitely confuse/overwhelm users IMO.

 It would be nice if the master pom is in the root directory of myfaces.

Yes it would but that would mean no external ;-)  That is the tradeoff.

 Some plugin (idea) are not working with the current structure.

Can you elaborate?  Is this because of the master POM not being in the
top level?

 Any comments

 Best Regards

 Bernd

Sean

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread chemeia

Let me know when the build environment is in a stable state again and I'll run another test build from here.

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread Wendy Smoak

On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:

 So 1.1.2 is defined in only the parent POM?  What if you want to build
 tomahawk by itself (without the parent pom?)

You can't build it without the parent pom-- the build will fail
because that pom is as much a 'dependency' as any of the jars you need
on the classpath.

 I think this is a tricky problem.  Also, if we ever release different
 version numbers for the subprojects won't this cause a problem?

Once 1.1.2 is in the repository, the versioned parent pom will be
there as well, and Maven will find it.

I don't see any relativePath tags in the parent sections.  If you
add them, Maven will look locally (on the filesystem) for the parent
pom as well as checking the repository.

Struts Action looks like this:
   parent
  groupIdstruts/groupId
  artifactIdstruts-build/artifactId
  version1.3.0-SNAPSHOT/version
  relativePathbuild/pom.xml/relativePath
   /parent

The 'build' directory is external, included under each module.  If
you're not doing that, you can use:
   relativePath../build/pom.xml/relativePath

I think that might help the IDE config file generation, though I'm not sure.

--
Wendy

Re: Maven Build (Ongoing Work Thread)

Sean,

I have tried to get the setup working with what Thomas proposed, and
it didn't work.

So there is no way to get the sandbox-examples up and running with
IntelliJ, except with having normal resources (aka belong to one
module alone) separated from the faces-config.xml file.

Tobagos, you are using IntelliJ as well. Do you guys have a
workaround? Do me a favor and try to setup the sandbox-examples with a
module-based structure and tell me that there is one ;)

regards,

Martin


On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
  Hello,
 
  please apply this patch to the pom in the build directory to simplfy the
  build process.
  Changes:
  Added default goal

 Good idea

  Removed tabs

 Sorry.  My fault.  I used UltraEdit instead of my IDE and the setting
 weren't right.

  Added www.atanion.com/maven2 as snapshot plugin repository

 OK as a temporary solution.  Eventually we should figure out the best
 mechanism for hosting our plugins on myfaces.apache.org.

  Changed list to List in mailingLists

 +1

  Changed finalname to myfaces-${version}

 Good idea.  I assume this means the version will be inherited from the
 pom?  I have been reading up on the filtering stuff as well.  I think
 we can stop hard coding the versions in the example webapps and use a
 message bundle with ${pom.version}.

  Skipped the tests until they are stable

 OK hopefully we get those fixed soon.

 
  With this patch the xslt-plugin is fetched from the atanion maven
  repositry, you don't need to install the xslt-plugin to your local
  repository manualy. I have deployed the xslt-plugin into the atanion
  maven repository (with the patch for
  http://jira.codehaus.org/browse/MOJO-203).
  Some other comments on the maven build to improve the build:
 
  Please use as much as possible the ${version} instead of hardcoding the
  version and remove the version tag if a parent pom exists(but not in
  the parent description see tobago poms).

 So 1.1.2 is defined in only the parent POM?  What if you want to build
 tomahawk by itself (without the parent pom?)

 I think this is a tricky problem.  Also, if we ever release different
 version numbers for the subprojects won't this cause a problem?

  Please move the assembly plugin configuration in the master pom to api
  or impl otherwise every subproject try to call the assembly plugin.

 Maybe we could have a special module called 'deploy'?  That would have
 the nightly build, assembly and release stuff in it?  I think that
 might be better then picking an arbitrary module like api.  What do
 you think?

  Can we removed the svn externals. With the maven build they are useless
  for api, impl, commons, tomahawk, sandbox..

 What do you mean useless?  We did get rid of the externals for the
 build dir which used to be in every subproject.  The only externals
 now are for current and a few for the TLD entities.

 I'm +1 for getting rid of them if we can do the same thing a different
 way.  But I think having the current external is good and its
 becoming a psuedo-standard.  Other projects (including) Struts adopt
 the same approach and its nice to have.

 Keep in mind under each subproject we have trunk, branches and tags.
 Without an external you would get the entire repository if you checked
 out the top level!  That would definitely confuse/overwhelm users IMO.

  It would be nice if the master pom is in the root directory of myfaces.

 Yes it would but that would mean no external ;-)  That is the tradeoff.

  Some plugin (idea) are not working with the current structure.

 Can you elaborate?  Is this because of the master POM not being in the
 top level?

  Any comments
 
  Best Regards
 
  Bernd

 Sean



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

Perhaps I was doing some wrong stuff,

in sandbox (and tomhawak) I have the folder /src/main/resource/META-INF

but the META-INF is not in svn (subclipse plugin for Eclipse told me),
so I guess it is *generated* during build...

however mvn clean doesn't remove the folders.

Can anyone clearify that I am doing (or not) wrong stuff ?

-Matthias


On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
 Do we even need the parent tags?  For certain projects (tomahawk) for
 instance, we want to be able to compile independent of myfaces, or
 more accurately, we want the option to do so.

 What advantages does the parent tag give us (other then sharing
 dependencies?)  I'm not sure we're even taking advantage of the
 dependency thing anyways.  I'm still finding my way around here ...

 Sean

 On 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
  On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
 
   So 1.1.2 is defined in only the parent POM?  What if you want to build
   tomahawk by itself (without the parent pom?)
 
  You can't build it without the parent pom-- the build will fail
  because that pom is as much a 'dependency' as any of the jars you need
  on the classpath.
 
   I think this is a tricky problem.  Also, if we ever release different
   version numbers for the subprojects won't this cause a problem?
 
  Once 1.1.2 is in the repository, the versioned parent pom will be
  there as well, and Maven will find it.
 
  I don't see any relativePath tags in the parent sections.  If you
  add them, Maven will look locally (on the filesystem) for the parent
  pom as well as checking the repository.
 
  Struts Action looks like this:
 parent
groupIdstruts/groupId
artifactIdstruts-build/artifactId
version1.3.0-SNAPSHOT/version
relativePathbuild/pom.xml/relativePath
 /parent
 
  The 'build' directory is external, included under each module.  If
  you're not doing that, you can use:
 relativePath../build/pom.xml/relativePath
 
  I think that might help the IDE config file generation, though I'm not sure.
 
  --
  Wendy
 



--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

Re: Maven Build (Ongoing Work Thread)

nevermind,

it works now... strange...
however, thanks :-)

On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Perhaps I was doing some wrong stuff,

 in sandbox (and tomhawak) I have the folder /src/main/resource/META-INF

 but the META-INF is not in svn (subclipse plugin for Eclipse told me),
 so I guess it is *generated* during build...

 however mvn clean doesn't remove the folders.

 Can anyone clearify that I am doing (or not) wrong stuff ?

 -Matthias


 On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
  Do we even need the parent tags?  For certain projects (tomahawk) for
  instance, we want to be able to compile independent of myfaces, or
  more accurately, we want the option to do so.
 
  What advantages does the parent tag give us (other then sharing
  dependencies?)  I'm not sure we're even taking advantage of the
  dependency thing anyways.  I'm still finding my way around here ...
 
  Sean
 
  On 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
   On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
  
So 1.1.2 is defined in only the parent POM?  What if you want to build
tomahawk by itself (without the parent pom?)
  
   You can't build it without the parent pom-- the build will fail
   because that pom is as much a 'dependency' as any of the jars you need
   on the classpath.
  
I think this is a tricky problem.  Also, if we ever release different
version numbers for the subprojects won't this cause a problem?
  
   Once 1.1.2 is in the repository, the versioned parent pom will be
   there as well, and Maven will find it.
  
   I don't see any relativePath tags in the parent sections.  If you
   add them, Maven will look locally (on the filesystem) for the parent
   pom as well as checking the repository.
  
   Struts Action looks like this:
  parent
 groupIdstruts/groupId
 artifactIdstruts-build/artifactId
 version1.3.0-SNAPSHOT/version
 relativePathbuild/pom.xml/relativePath
  /parent
  
   The 'build' directory is external, included under each module.  If
   you're not doing that, you can use:
  relativePath../build/pom.xml/relativePath
  
   I think that might help the IDE config file generation, though I'm not 
   sure.
  
   --
   Wendy
  
 


 --
 Matthias Wessendorf
 Zülpicher Wall 12, 239
 50674 Köln
 http://www.wessendorf.net
 mwessendorf-at-gmail-dot-com



--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

Re: Maven Build (Ongoing Work Thread)

This has been deleted by me - and moved to its own directory (see my
mail about problems with IntelliJ). I think subversion update doesn't
remove a directory if it is deleted on the server, so you are left
with out-of-date local versions!

regards,

Martin

On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Perhaps I was doing some wrong stuff,

 in sandbox (and tomhawak) I have the folder /src/main/resource/META-INF

 but the META-INF is not in svn (subclipse plugin for Eclipse told me),
 so I guess it is *generated* during build...

 however mvn clean doesn't remove the folders.

 Can anyone clearify that I am doing (or not) wrong stuff ?

 -Matthias


 On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
  Do we even need the parent tags?  For certain projects (tomahawk) for
  instance, we want to be able to compile independent of myfaces, or
  more accurately, we want the option to do so.
 
  What advantages does the parent tag give us (other then sharing
  dependencies?)  I'm not sure we're even taking advantage of the
  dependency thing anyways.  I'm still finding my way around here ...
 
  Sean
 
  On 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
   On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
  
So 1.1.2 is defined in only the parent POM?  What if you want to build
tomahawk by itself (without the parent pom?)
  
   You can't build it without the parent pom-- the build will fail
   because that pom is as much a 'dependency' as any of the jars you need
   on the classpath.
  
I think this is a tricky problem.  Also, if we ever release different
version numbers for the subprojects won't this cause a problem?
  
   Once 1.1.2 is in the repository, the versioned parent pom will be
   there as well, and Maven will find it.
  
   I don't see any relativePath tags in the parent sections.  If you
   add them, Maven will look locally (on the filesystem) for the parent
   pom as well as checking the repository.
  
   Struts Action looks like this:
  parent
 groupIdstruts/groupId
 artifactIdstruts-build/artifactId
 version1.3.0-SNAPSHOT/version
 relativePathbuild/pom.xml/relativePath
  /parent
  
   The 'build' directory is external, included under each module.  If
   you're not doing that, you can use:
  relativePath../build/pom.xml/relativePath
  
   I think that might help the IDE config file generation, though I'm not 
   sure.
  
   --
   Wendy
  
 


 --
 Matthias Wessendorf
 Zülpicher Wall 12, 239
 50674 Köln
 http://www.wessendorf.net
 mwessendorf-at-gmail-dot-com



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

I believe subversion does delete the dirs when you remove a directory.
 Most likely your *client* (Eclipse?) has a bug.  I know all of the
dirs from the maven reorg that needed to be deleted were deleted
automatically by tortoise-cvs.

By the way, if you use windows you should consider tortoise-cvs.  It
is an awesome client!  Its so good that I don't mind that its not
integrated with my IDE.

I want to get back to Martin's (and now Matthias') issue with the IDE
but I have a few things to deal with first.  I'm sure we can figure
out a better solution then what we have now ...

Sean

On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 This has been deleted by me - and moved to its own directory (see my
 mail about problems with IntelliJ). I think subversion update doesn't
 remove a directory if it is deleted on the server, so you are left
 with out-of-date local versions!

 regards,

 Martin

 On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Perhaps I was doing some wrong stuff,
 
  in sandbox (and tomhawak) I have the folder /src/main/resource/META-INF
 
  but the META-INF is not in svn (subclipse plugin for Eclipse told me),
  so I guess it is *generated* during build...
 
  however mvn clean doesn't remove the folders.
 
  Can anyone clearify that I am doing (or not) wrong stuff ?
 
  -Matthias
 
 
  On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
   Do we even need the parent tags?  For certain projects (tomahawk) for
   instance, we want to be able to compile independent of myfaces, or
   more accurately, we want the option to do so.
  
   What advantages does the parent tag give us (other then sharing
   dependencies?)  I'm not sure we're even taking advantage of the
   dependency thing anyways.  I'm still finding my way around here ...
  
   Sean
  
   On 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
   
 So 1.1.2 is defined in only the parent POM?  What if you want to build
 tomahawk by itself (without the parent pom?)
   
You can't build it without the parent pom-- the build will fail
because that pom is as much a 'dependency' as any of the jars you need
on the classpath.
   
 I think this is a tricky problem.  Also, if we ever release different
 version numbers for the subprojects won't this cause a problem?
   
Once 1.1.2 is in the repository, the versioned parent pom will be
there as well, and Maven will find it.
   
I don't see any relativePath tags in the parent sections.  If you
add them, Maven will look locally (on the filesystem) for the parent
pom as well as checking the repository.
   
Struts Action looks like this:
   parent
  groupIdstruts/groupId
  artifactIdstruts-build/artifactId
  version1.3.0-SNAPSHOT/version
  relativePathbuild/pom.xml/relativePath
   /parent
   
The 'build' directory is external, included under each module.  If
you're not doing that, you can use:
   relativePath../build/pom.xml/relativePath
   
I think that might help the IDE config file generation, though I'm not 
sure.
   
--
Wendy
   
  
 
 
  --
  Matthias Wessendorf
  Zülpicher Wall 12, 239
  50674 Köln
  http://www.wessendorf.net
  mwessendorf-at-gmail-dot-com
 


 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)


Hello Matthias,

you are not doing wrong stuff the destDir for the tld stuff has changed 
from src/main/resources/META-INF to target/classes/META-INF.


You can delete the old META-INF in src/main/resources.
Generated sources, classes... should only created in the 'target' dir :-).

Best Regards

Bernd


Matthias Wessendorf schrieb:

Perhaps I was doing some wrong stuff,

in sandbox (and tomhawak) I have the folder /src/main/resource/META-INF

but the META-INF is not in svn (subclipse plugin for Eclipse told me),
so I guess it is *generated* during build...

however mvn clean doesn't remove the folders.

Can anyone clearify that I am doing (or not) wrong stuff ?

-Matthias


On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:


Do we even need the parent tags?  For certain projects (tomahawk) for
instance, we want to be able to compile independent of myfaces, or
more accurately, we want the option to do so.

What advantages does the parent tag give us (other then sharing
dependencies?)  I'm not sure we're even taking advantage of the
dependency thing anyways.  I'm still finding my way around here ...

Sean

On 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:


On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:



So 1.1.2 is defined in only the parent POM?  What if you want to build
tomahawk by itself (without the parent pom?)


You can't build it without the parent pom-- the build will fail
because that pom is as much a 'dependency' as any of the jars you need
on the classpath.



I think this is a tricky problem.  Also, if we ever release different
version numbers for the subprojects won't this cause a problem?


Once 1.1.2 is in the repository, the versioned parent pom will be
there as well, and Maven will find it.

I don't see any relativePath tags in the parent sections.  If you
add them, Maven will look locally (on the filesystem) for the parent
pom as well as checking the repository.

Struts Action looks like this:
  parent
 groupIdstruts/groupId
 artifactIdstruts-build/artifactId
 version1.3.0-SNAPSHOT/version
 relativePathbuild/pom.xml/relativePath
  /parent

The 'build' directory is external, included under each module.  If
you're not doing that, you can use:
  relativePath../build/pom.xml/relativePath

I think that might help the IDE config file generation, though I'm not sure.

--
Wendy






--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

bernd,

solved ;)



On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 Hello Matthias,

 you are not doing wrong stuff the destDir for the tld stuff has changed
 from src/main/resources/META-INF to target/classes/META-INF.

 You can delete the old META-INF in src/main/resources.
 Generated sources, classes... should only created in the 'target' dir :-).

 Best Regards

 Bernd


 Matthias Wessendorf schrieb:
  Perhaps I was doing some wrong stuff,
 
  in sandbox (and tomhawak) I have the folder /src/main/resource/META-INF
 
  but the META-INF is not in svn (subclipse plugin for Eclipse told me),
  so I guess it is *generated* during build...
 
  however mvn clean doesn't remove the folders.
 
  Can anyone clearify that I am doing (or not) wrong stuff ?
 
  -Matthias
 
 
  On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
 
 Do we even need the parent tags?  For certain projects (tomahawk) for
 instance, we want to be able to compile independent of myfaces, or
 more accurately, we want the option to do so.
 
 What advantages does the parent tag give us (other then sharing
 dependencies?)  I'm not sure we're even taking advantage of the
 dependency thing anyways.  I'm still finding my way around here ...
 
 Sean
 
 On 1/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
 
 On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
 
 
 So 1.1.2 is defined in only the parent POM?  What if you want to build
 tomahawk by itself (without the parent pom?)
 
 You can't build it without the parent pom-- the build will fail
 because that pom is as much a 'dependency' as any of the jars you need
 on the classpath.
 
 
 I think this is a tricky problem.  Also, if we ever release different
 version numbers for the subprojects won't this cause a problem?
 
 Once 1.1.2 is in the repository, the versioned parent pom will be
 there as well, and Maven will find it.
 
 I don't see any relativePath tags in the parent sections.  If you
 add them, Maven will look locally (on the filesystem) for the parent
 pom as well as checking the repository.
 
 Struts Action looks like this:
parent
   groupIdstruts/groupId
   artifactIdstruts-build/artifactId
   version1.3.0-SNAPSHOT/version
   relativePathbuild/pom.xml/relativePath
/parent
 
 The 'build' directory is external, included under each module.  If
 you're not doing that, you can use:
relativePath../build/pom.xml/relativePath
 
 I think that might help the IDE config file generation, though I'm not 
 sure.
 
 --
 Wendy
 
 
 
 
  --
  Matthias Wessendorf
  Zülpicher Wall 12, 239
  50674 Köln
  http://www.wessendorf.net
  mwessendorf-at-gmail-dot-com
 

 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333



--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com

Re: Maven Build (Ongoing Work Thread)

damn,

 you are not doing wrong stuff the destDir for the tld stuff has changed
 from src/main/resources/META-INF to target/classes/META-INF.

looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF

8-)

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread John Fallows

On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
By the way, if you use windows you should consider tortoise-cvs.Itis an awesome client!Its so good that I don't mind that its notintegrated with my IDE.You mean TortoiseSVN of course, which was inspired by TortoiseCVS. :-)
http://tortoisesvn.sourceforge.net/http://tortoisesvn.tigris.org/

Kind Regards,
John Fallows-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread Travis Reeder

FYI, just trying out this new maven build and I noticed that the faces-config.xml are not being put in the jars, myfaces-sandbox-1.1.2-SNAPSHOT.jar, tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.
So when trying to run examples, the components are undefined.TravisOn 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]
 wrote:damn, you are not doing wrong stuff the destDir for the tld stuff has changed
 from src/main/resources/META-INF to target/classes/META-INF.looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF8-)

Re: Maven Build (Ongoing Work Thread)

Oh cool - so additonal directories like my
src/main/resources-facesconfig are not treated as source directories?

Is there a way to change the settings of Maven so those are included?

regards,

Martin

On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
 FYI, just trying out this new maven build and I noticed that the
 faces-config.xml are not being put in the jars,
 myfaces-sandbox-1.1.2-SNAPSHOT.jar,
 tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.

  So when trying to run examples, the components are undefined.

 Travis

 On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
  damn,
 
   you are not doing wrong stuff the destDir for the tld stuff has changed
   from src/main/resources/META-INF to target/classes/META-INF.
 
  looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF
 
  8-)
 




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

Right that's what I meant.  I use tortoise-cvs here at work ;-)

sean

On 1/3/06, John Fallows [EMAIL PROTECTED] wrote:
 On 1/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
  By the way, if you use windows you should consider tortoise-cvs.  It
  is an awesome client!  Its so good that I don't mind that its not
  integrated with my IDE.

 You mean TortoiseSVN of course, which was inspired by TortoiseCVS. :-)

 http://tortoisesvn.sourceforge.net/
 http://tortoisesvn.tigris.org/

  Kind Regards,
  John Fallows

 --
 Author Pro JSF and Ajax: Building Rich Internet Components
 http://www.apress.com/book/bookDisplay.html?bID=10044

Re: Maven Build (Ongoing Work Thread)

Interesting.  The examples were working earlier.  Perhaps Martin's
directory change broke this?  I seemed to recall running the examples
successfuly *after* this change though ...

I will try to look into it tonight (if nobody has solved by then.)

Sean

On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
 FYI, just trying out this new maven build and I noticed that the
 faces-config.xml are not being put in the jars,
 myfaces-sandbox-1.1.2-SNAPSHOT.jar,
 tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.

  So when trying to run examples, the components are undefined.

 Travis

 On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
  damn,
 
   you are not doing wrong stuff the destDir for the tld stuff has changed
   from src/main/resources/META-INF to target/classes/META-INF.
 
  looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF
 
  8-)

Re: Maven Build (Ongoing Work Thread)

That sounds like something I might have done.  Sorry about that.  I
think I was experimenting with the resources and changed the dirs
around.

Sean

On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 damn,

  you are not doing wrong stuff the destDir for the tld stuff has changed
  from src/main/resources/META-INF to target/classes/META-INF.

 looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF

 8-)

Re: Maven Build (Ongoing Work Thread)

Yes you can specify resource directives in your POM.  Having a
single resource dir is an advantage in that you don't have to do this
(its done for you automatically.)  That's one reason why I'd like to
get back to the single dir.  Less overhead and maintenance.

Sean

On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Oh cool - so additonal directories like my
 src/main/resources-facesconfig are not treated as source directories?

 Is there a way to change the settings of Maven so those are included?

 regards,

 Martin

 On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
  FYI, just trying out this new maven build and I noticed that the
  faces-config.xml are not being put in the jars,
  myfaces-sandbox-1.1.2-SNAPSHOT.jar,
  tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.
 
   So when trying to run examples, the components are undefined.
 
  Travis
 
  On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
   damn,
  
you are not doing wrong stuff the destDir for the tld stuff has changed
from src/main/resources/META-INF to target/classes/META-INF.
  
   looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF
  
   8-)
  
 
 


 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)


Hello,

what was the reason for the additional directory?

Bernd

Sean Schofield schrieb:

Yes you can specify resource directives in your POM.  Having a
single resource dir is an advantage in that you don't have to do this
(its done for you automatically.)  That's one reason why I'd like to
get back to the single dir.  Less overhead and maintenance.

Sean

On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:


Oh cool - so additonal directories like my
src/main/resources-facesconfig are not treated as source directories?

Is there a way to change the settings of Maven so those are included?

regards,

Martin

On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:


FYI, just trying out this new maven build and I noticed that the
faces-config.xml are not being put in the jars,
myfaces-sandbox-1.1.2-SNAPSHOT.jar,
tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.

So when trying to run examples, the components are undefined.

Travis

On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:


damn,



you are not doing wrong stuff the destDir for the tld stuff has changed
from src/main/resources/META-INF to target/classes/META-INF.


looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF

8-)






--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces






--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

Try to setup the sandbox examples in IntelliJ

- you need both faces-config.xml from tomahawk and the
faces-config.xml from sandbox.

You can't add them if they are not in separated directories from the
other resources which need to go along the sourcecode.

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 Hello,

 what was the reason for the additional directory?

 Bernd

 Sean Schofield schrieb:
  Yes you can specify resource directives in your POM.  Having a
  single resource dir is an advantage in that you don't have to do this
  (its done for you automatically.)  That's one reason why I'd like to
  get back to the single dir.  Less overhead and maintenance.
 
  Sean
 
  On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 
 Oh cool - so additonal directories like my
 src/main/resources-facesconfig are not treated as source directories?
 
 Is there a way to change the settings of Maven so those are included?
 
 regards,
 
 Martin
 
 On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
 
 FYI, just trying out this new maven build and I noticed that the
 faces-config.xml are not being put in the jars,
 myfaces-sandbox-1.1.2-SNAPSHOT.jar,
 tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.
 
  So when trying to run examples, the components are undefined.
 
 Travis
 
 On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
 
 damn,
 
 
 you are not doing wrong stuff the destDir for the tld stuff has changed
 from src/main/resources/META-INF to target/classes/META-INF.
 
 looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF
 
 8-)
 
 
 
 
 --
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 

 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread Travis Reeder

I've just checked in some pom changes that add the resources-facesconfig directories. TravisOn 1/3/06, Martin Marinschek 
[EMAIL PROTECTED] wrote:Try to setup the sandbox examples in IntelliJ
- you need both faces-config.xml from tomahawk and thefaces-config.xml from sandbox.You can't add them if they are not in separated directories from theother resources which need to go along the sourcecode.
regards,MartinOn 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello, what was the reason for the additional directory?
 Bernd Sean Schofield schrieb:  Yes you can specify resource directives in your POM.Having a  single resource dir is an advantage in that you don't have to do this
  (its done for you automatically.)That's one reason why I'd like to  get back to the single dir.Less overhead and maintenance.   Sean   On 1/3/06, Martin Marinschek 
[EMAIL PROTECTED] wrote:  Oh cool - so additonal directories like my src/main/resources-facesconfig are not treated as source directories?
  Is there a way to change the settings of Maven so those are included?  regards,  Martin  On 1/3/06, Travis Reeder 
[EMAIL PROTECTED] wrote:  FYI, just trying out this new maven build and I noticed that the faces-config.xml are not being put in the jars,
 myfaces-sandbox-1.1.2-SNAPSHOT.jar, tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.   So when trying to run examples, the components are undefined.
  Travis  On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote: 
 damn,   you are not doing wrong stuff the destDir for the tld stuff has changed from src/main/resources/META-INF to target/classes/META-INF.
  looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF  8-)  
   --  http://www.irian.at  Your JSF powerhouse - JSF Consulting, Development and
 Courses in English and German  Professional Support for Apache MyFaces-- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333--
http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)


.
Maybe a better way is to separate the examples from the other artifacts.
Then mvn idea:idea whould add tomahawk and sandbox as lib.

We should talk about this and did not define more directories and add 
more configuration options in the pom's.


Bernd



Martin Marinschek schrieb:

Try to setup the sandbox examples in IntelliJ

- you need both faces-config.xml from tomahawk and the
faces-config.xml from sandbox.

You can't add them if they are not in separated directories from the
other resources which need to go along the sourcecode.

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:


Hello,

what was the reason for the additional directory?

Bernd

Sean Schofield schrieb:


Yes you can specify resource directives in your POM.  Having a
single resource dir is an advantage in that you don't have to do this
(its done for you automatically.)  That's one reason why I'd like to
get back to the single dir.  Less overhead and maintenance.

Sean

On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:



Oh cool - so additonal directories like my
src/main/resources-facesconfig are not treated as source directories?

Is there a way to change the settings of Maven so those are included?

regards,

Martin

On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:



FYI, just trying out this new maven build and I noticed that the
faces-config.xml are not being put in the jars,
myfaces-sandbox-1.1.2-SNAPSHOT.jar,
tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.

So when trying to run examples, the components are undefined.

Travis

On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:



damn,




you are not doing wrong stuff the destDir for the tld stuff has changed



from src/main/resources/META-INF to target/classes/META-INF.


looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF

8-)





--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces





--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333





--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

Well,

I know next to nothing about Maven, but had to get the examples working.

What do you mean by your first proposal?

I don't want to end up with a solution where I do a change in the
MyFaces code and then have to run maven before I can start the
examples-app.

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 .
 Maybe a better way is to separate the examples from the other artifacts.
 Then mvn idea:idea whould add tomahawk and sandbox as lib.

 We should talk about this and did not define more directories and add
 more configuration options in the pom's.

 Bernd



 Martin Marinschek schrieb:
  Try to setup the sandbox examples in IntelliJ
 
  - you need both faces-config.xml from tomahawk and the
  faces-config.xml from sandbox.
 
  You can't add them if they are not in separated directories from the
  other resources which need to go along the sourcecode.
 
  regards,
 
  Martin
 
  On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 
 Hello,
 
 what was the reason for the additional directory?
 
 Bernd
 
 Sean Schofield schrieb:
 
 Yes you can specify resource directives in your POM.  Having a
 single resource dir is an advantage in that you don't have to do this
 (its done for you automatically.)  That's one reason why I'd like to
 get back to the single dir.  Less overhead and maintenance.
 
 Sean
 
 On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 
 
 Oh cool - so additonal directories like my
 src/main/resources-facesconfig are not treated as source directories?
 
 Is there a way to change the settings of Maven so those are included?
 
 regards,
 
 Martin
 
 On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
 
 
 FYI, just trying out this new maven build and I noticed that the
 faces-config.xml are not being put in the jars,
 myfaces-sandbox-1.1.2-SNAPSHOT.jar,
 tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.
 
 So when trying to run examples, the components are undefined.
 
 Travis
 
 On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
 
 
 damn,
 
 
 
 you are not doing wrong stuff the destDir for the tld stuff has changed
 
 from src/main/resources/META-INF to target/classes/META-INF.
 
 looking at pom.xml (mojo plugin stuff) I now see 
 target/clazzes/META-INF
 
 8-)
 
 
 
 --
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
 
 
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 

 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)


It means want you don't want.

Martin Marinschek schrieb:

Well,

I know next to nothing about Maven, but had to get the examples working.

What do you mean by your first proposal?

I don't want to end up with a solution where I do a change in the
MyFaces code and then have to run maven before I can start the
examples-app.

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:


.
Maybe a better way is to separate the examples from the other artifacts.
Then mvn idea:idea whould add tomahawk and sandbox as lib.

We should talk about this and did not define more directories and add
more configuration options in the pom's.

Bernd



Martin Marinschek schrieb:


Try to setup the sandbox examples in IntelliJ

- you need both faces-config.xml from tomahawk and the
faces-config.xml from sandbox.

You can't add them if they are not in separated directories from the
other resources which need to go along the sourcecode.

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:



Hello,

what was the reason for the additional directory?

Bernd

Sean Schofield schrieb:



Yes you can specify resource directives in your POM.  Having a
single resource dir is an advantage in that you don't have to do this
(its done for you automatically.)  That's one reason why I'd like to
get back to the single dir.  Less overhead and maintenance.

Sean

On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:




Oh cool - so additonal directories like my
src/main/resources-facesconfig are not treated as source directories?

Is there a way to change the settings of Maven so those are included?

regards,

Martin

On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:




FYI, just trying out this new maven build and I noticed that the
faces-config.xml are not being put in the jars,
myfaces-sandbox-1.1.2-SNAPSHOT.jar,
tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.

So when trying to run examples, the components are undefined.

Travis

On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:




damn,





you are not doing wrong stuff the destDir for the tld stuff has changed



from src/main/resources/META-INF to target/classes/META-INF.


looking at pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF

8-)





--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces





--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333





--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333





--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

;)

bahh!

Martin no like!

regards,

Martin

On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 It means want you don't want.

 Martin Marinschek schrieb:
  Well,
 
  I know next to nothing about Maven, but had to get the examples working.
 
  What do you mean by your first proposal?
 
  I don't want to end up with a solution where I do a change in the
  MyFaces code and then have to run maven before I can start the
  examples-app.
 
  regards,
 
  Martin
 
  On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 
 .
 Maybe a better way is to separate the examples from the other artifacts.
 Then mvn idea:idea whould add tomahawk and sandbox as lib.
 
 We should talk about this and did not define more directories and add
 more configuration options in the pom's.
 
 Bernd
 
 
 
 Martin Marinschek schrieb:
 
 Try to setup the sandbox examples in IntelliJ
 
 - you need both faces-config.xml from tomahawk and the
 faces-config.xml from sandbox.
 
 You can't add them if they are not in separated directories from the
 other resources which need to go along the sourcecode.
 
 regards,
 
 Martin
 
 On 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 
 
 Hello,
 
 what was the reason for the additional directory?
 
 Bernd
 
 Sean Schofield schrieb:
 
 
 Yes you can specify resource directives in your POM.  Having a
 single resource dir is an advantage in that you don't have to do this
 (its done for you automatically.)  That's one reason why I'd like to
 get back to the single dir.  Less overhead and maintenance.
 
 Sean
 
 On 1/3/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 
 
 
 Oh cool - so additonal directories like my
 src/main/resources-facesconfig are not treated as source directories?
 
 Is there a way to change the settings of Maven so those are included?
 
 regards,
 
 Martin
 
 On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
 
 
 
 FYI, just trying out this new maven build and I noticed that the
 faces-config.xml are not being put in the jars,
 myfaces-sandbox-1.1.2-SNAPSHOT.jar,
 tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar.
 
 So when trying to run examples, the components are undefined.
 
 Travis
 
 On 1/3/06, Matthias Wessendorf [EMAIL PROTECTED]  wrote:
 
 
 
 damn,
 
 
 
 
 you are not doing wrong stuff the destDir for the tld stuff has 
 changed
 
 from src/main/resources/META-INF to target/classes/META-INF.
 
 looking at pom.xml (mojo plugin stuff) I now see 
 target/clazzes/META-INF
 
 8-)
 
 
 
 --
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 
 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
 
 
 
 
 --
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
 
 
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 

 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread Travis Reeder

ditto! Takes over 30 seconds to run the maven build, anyway to speed it up if we have to go down this path?On 1/3/06, Martin Marinschek
[EMAIL PROTECTED] wrote:;)bahh!Martin no like!
regards,MartinOn 1/3/06, Bernd Bohmann [EMAIL PROTECTED] wrote: It means want you don't want. Martin Marinschek schrieb:
Well, I know next to nothing about Maven, but had to get the examples working. What do you mean by your first proposal? I don't want to end up with a solution where I do a change in the
MyFaces code and then have to run maven before I can start the examples-app. regards, Martin On 1/3/06, Bernd Bohmann
[EMAIL PROTECTED] wrote: . Maybe a better way is to separate the examples from the other artifacts. Then mvn idea:idea whould add tomahawk and sandbox as lib.
We should talk about this and did not define more directories and add more configuration options in the pom's. Bernd
Martin Marinschek schrieb: Try to setup the sandbox examples in IntelliJ - you need both faces-config.xml from tomahawk and the
faces-config.xml from sandbox. You can't add them if they are not in separated directories from the other resources which need to go along the sourcecode.
regards, Martin On 1/3/06, Bernd Bohmann [EMAIL PROTECTED]
wrote: Hello, what was the reason for the additional directory? Bernd
Sean Schofield schrieb: Yes you can specify resource directives in your POM.Having a
single resource dir is an advantage in that you don't have to do this (its done for you automatically.)That's one reason why I'd like to get back to the single dir.Less overhead and maintenance.
Sean On 1/3/06, Martin Marinschek [EMAIL PROTECTED]
wrote:Oh cool - so additonal directories like my src/main/resources-facesconfig are not treated as source directories?
Is there a way to change the settings of Maven so those are included? regards,
Martin On 1/3/06, Travis Reeder [EMAIL PROTECTED] wrote:
FYI, just trying out this new maven build and I noticed that the faces-config.xml are not being put in the jars,
myfaces-sandbox-1.1.2-SNAPSHOT.jar, tomahawk-1.1.2-SNAPSHOT.jar, and myfaces-impl-1.1.2-SNAPSHOT.jar. So when trying to run examples, the components are undefined.
Travis On 1/3/06, Matthias Wessendorf
[EMAIL PROTECTED] wrote:damn,
you are not doing wrong stuff the destDir for the tld stuff has changed
from src/main/resources/META-INF to target/classes/META-INF. looking at
pom.xml (mojo plugin stuff) I now see target/clazzes/META-INF 8-)
-- http://www.irian.at
Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
-- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg,
http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and
Courses in English and German Professional Support for Apache MyFaces -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German
Professional Support for Apache MyFaces -- Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development Bismarckstr. 13, 26122 Oldenburg,
http://www.atanion.com phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333--http://www.irian.atYour JSF powerhouse -JSF Consulting, Development and
Courses in English and GermanProfessional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

2006-01-03 Thread Volker Weber

Hi Martin,

what exact is the problem with setup the sandbox examples in idea?

I just made a 'mvn idea:idea' in common, api, impl, tomahawk, sandbox,
and examples/sandbox dirs.
After creating a new 'multi module' idea project and adding the created
*.iml, i just neet to setup the dependencies.

I haven't realy worked with this setup, but it seems to be ok. changing
of a class in tomahawk is directly available in sandbox example code.
no need to run maven beetwen.

Martin Marinschek wrote:
 Well,
 
 I know next to nothing about Maven, but had to get the examples working.
 
 What do you mean by your first proposal?
 
 I don't want to end up with a solution where I do a change in the
 MyFaces code and then have to run maven before I can start the
 examples-app.
 

What did you mean with 'before I can start the examples-app'?
You don't want to have the changes running in tomcat without rebuild and
deploy the jar/war ?

Regards
  Volker

-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread Volker Weber

Hi,

IMHO there should no created artifacts outside of the target directory.

AFAIK the tlds are created ?

Everything in target is removed on 'mvn clean'.

In tobago we have the created tobago.tld in 'target/classes/META-INF/...'.

Regards
  Volker

Martin Marinschek wrote:
 Ok, I just refactored the resources directory into a:
 
 resources-tld - all tld files wander into this one
 resources-facesconfig - the config files are situated there and
 resources - for all other (normal) stuff
 
 this might also make it easier to adopt maven-clean; you'd only need
 to throw away everything in resources-tld.
 
-- 
Don't answer to From: address!
Mail to this account are droped if not recieved via mailinglist.
To contact me direct create the mail address by
concatenating my forename to my senders domain.

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread Werner Punz

[EMAIL PROTECTED] wrote:
 Thanks for the pointer.  I saw the eclipse:eclipse plugin but like to do
 things the old fashioned way the first time to understand what's going on.
 
 Sean, not sure what you're meaning by your comment.  Are you suggesting
 adding each of the libraries from ~/.m2/repository/... to the project? 
I am not sure if the eclipse plugin currently is really that usable,
it is very beta currently, you can mavenize a project with it currently
and add dependencies, but somehow there seems to be now way to define
a build target.
Going with the command line mvn command probably might be the better choice.
(The maven1 plugin definitely was further than the m2 plugin the last
time I checked it out)

Re: Maven Build (Ongoing Work Thread)

Sounds like a good idea to me!

For me, it's important in any case to be able to split up the
resources in the different types, with this, I have different
directories for inclusion into different IntelliJ modules. Without
that, I'm stranded ;)

regards,

Martin

On 1/2/06, Volker Weber [EMAIL PROTECTED] wrote:
 Hi,

 IMHO there should no created artifacts outside of the target directory.

 AFAIK the tlds are created ?

 Everything in target is removed on 'mvn clean'.

 In tobago we have the created tobago.tld in 'target/classes/META-INF/...'.

 Regards
   Volker

 Martin Marinschek wrote:
  Ok, I just refactored the resources directory into a:
 
  resources-tld - all tld files wander into this one
  resources-facesconfig - the config files are situated there and
  resources - for all other (normal) stuff
 
  this might also make it easier to adopt maven-clean; you'd only need
  to throw away everything in resources-tld.
 
 --
 Don't answer to From: address!
 Mail to this account are droped if not recieved via mailinglist.
 To contact me direct create the mail address by
 concatenating my forename to my senders domain.



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread Martin van den Bemt

No as a classpath variable in the eclipse configuration 
Window/Preferences/Java/Build Path/ClassPath Variable.


Mvgr,
Martin

[EMAIL PROTECTED] wrote:
Thanks for the pointer.  I saw the eclipse:eclipse plugin but like to do 
things the old fashioned way the first time to understand what's going on.


Sean, not sure what you're meaning by your comment.  Are you suggesting 
adding each of the libraries from ~/.m2/repository/... to the project?

Re: Maven Build (Ongoing Work Thread)

I'm not so sure this is a good idea to split up the resources. This
seems to violate the preferred Maven layout. Also, its kind of messy.
I definitely prefer a top level resoures dir. Again, I believe this
is the Maven standard.

What is it about IntelliJ that doesn't allow these files to be in the
same dir? By the way, I think we should listen to Volker about not
creating artifacts (including the TLD) in anything but the target
dir. This way, clean will work automatically. I will take care of
this now. Later, I'd like to switch the resources back the way they
were. Lets figure out a better way to solve your IDE issue.

Regards,

Sean

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Ok, I just refactored the resources directory into a:

resources-tld - all tld files wander into this one
resources-facesconfig - the config files are situated there and
resources - for all other (normal) stuff

this might also make it easier to adopt maven-clean; you'd only need
to throw away everything in resources-tld.

I've got that to run in IntelliJ no problem, short instructions as following:

- use mvn idea:idea (thanks Wendy for that hint!) to create a project file
- adopt the dependencies between the created modules as necessary,
- edit myfaces-examples-simple, add as a content-root all
src/main/resources-tld and src/main/resources-facesconfig directories
of impl and tomahawk.
- edit the web-module-settings - make sure to include the correct
libs, and ensure that the copy files to option is enabled for them
(_exclude_ commons-el and jsp2.0.jar - yes, really I've done it again
;)
- add the /META-INF sub-directories of the above-added content-roots
as web-resource-directories, using a path relative to deployment root
of /WEB-INF

it would be great if someone could update

http://wiki.apache.org/myfaces/JetBrains_IntelliJ_IDEA

with a little fleshed out version of this info ;)

regards,

Martin

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Same problem here -

plus I don't find a way to get the current structure up and running in
IntelliJ.

Anyone successful so far? Particularly, I don't find a way to include
my tld+faces-config.xml files properly - without loosing e.g. the
standard-faces-config.xml file.

Is there a way to split this up in impl, particularly have

src/main/java
src/main/resource_tld/META-INF/tlds
src/main/resource/rest of resources

plus - shouldn't we rename tomahawk to myfaces-tomahawk - if all other
projects have this name prefix?

regards,

Martin

On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Changes to the TLD files don't seem to be being picked up at build time;
this was a problem in the Ant build as well but 'ant clean' fixed it
there,
but 'mvn clean' doesn't here.

My situation: I editied
tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'. My changes didn't take, so I did a 'mvn clean'
then
a 'mvn install'. Changes still aren't picked up.

I suspect it's the cached intermediate file at
tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem. It isn't deleted by a clean.

[INFO]

[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]

[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:
C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

The thing is that I need those directories in the
myfaces-example-simple module - and as soon as I include it in this
module, it can't be used in any other module anymore.

If you find a way to work around this, you are free to change the
layout back, if not, please don't.

I wouldn't say its messy, the MAVEN-documentation speaks about
additional directories in the src/main-directory to be possible. I
don't see why lumping all different kinds of resources together into
one directory would help anything with a clean setup?

In short, I've invested several hours to get it up and running like this...

I don't have a problem with tld generation in the target-directory.
That sounds good to me! As long as it is in a separate directory from
the faces-config.xml's and the other resources.

regards,

Martin

On 1/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm not so sure this is a good idea to split up the resources. This
seems to violate the preferred Maven layout. Also, its kind of messy.
I definitely prefer a top level resoures dir. Again, I believe this
is the Maven standard.

Regards,

Sean

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Ok, I just refactored the resources directory into a:

resources-tld - all tld files wander into this one
resources-facesconfig - the config files are situated there and
resources - for all other (normal) stuff

this might also make it easier to adopt maven-clean; you'd only need
to throw away everything in resources-tld.

I've got that to run in IntelliJ no problem, short instructions as
following:

it would be great if someone could update

http://wiki.apache.org/myfaces/JetBrains_IntelliJ_IDEA

with a little fleshed out version of this info ;)

regards,

Martin

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Same problem here -

plus I don't find a way to get the current structure up and running in
IntelliJ.

Anyone successful so far? Particularly, I don't find a way to include
my tld+faces-config.xml files properly - without loosing e.g. the
standard-faces-config.xml file.

Is there a way to split this up in impl, particularly have

src/main/java
src/main/resource_tld/META-INF/tlds
src/main/resource/rest of resources

plus - shouldn't we rename tomahawk to myfaces-tomahawk - if all other
projects have this name prefix?

regards,

Martin

I suspect it's the cached intermediate file at
tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem. It isn't deleted by a clean.

[INFO]

[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]

[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:
C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Re: Maven Build (Ongoing Work Thread)

Sean,

I just talked with Thomas, and maybe we'll find a workaround. If I
find one, I'll change the directory structure back.

regards,

Martin

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
The thing is that I need those directories in the
myfaces-example-simple module - and as soon as I include it in this
module, it can't be used in any other module anymore.

If you find a way to work around this, you are free to change the
layout back, if not, please don't.

In short, I've invested several hours to get it up and running like this...

I don't have a problem with tld generation in the target-directory.
That sounds good to me! As long as it is in a separate directory from
the faces-config.xml's and the other resources.

regards,

Martin

Regards,

Sean

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Ok, I just refactored the resources directory into a:

resources-tld - all tld files wander into this one
resources-facesconfig - the config files are situated there and
resources - for all other (normal) stuff

this might also make it easier to adopt maven-clean; you'd only need
to throw away everything in resources-tld.

I've got that to run in IntelliJ no problem, short instructions as
following:

it would be great if someone could update

http://wiki.apache.org/myfaces/JetBrains_IntelliJ_IDEA

with a little fleshed out version of this info ;)

regards,

Martin

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
Same problem here -

plus I don't find a way to get the current structure up and running in
IntelliJ.

Anyone successful so far? Particularly, I don't find a way to include
my tld+faces-config.xml files properly - without loosing e.g. the
standard-faces-config.xml file.

Is there a way to split this up in impl, particularly have

src/main/java
src/main/resource_tld/META-INF/tlds
src/main/resource/rest of resources

plus - shouldn't we rename tomahawk to myfaces-tomahawk - if all other
projects have this name prefix?

regards,

Martin

On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Changes to the TLD files don't seem to be being picked up at build
time;
this was a problem in the Ant build as well but 'ant clean' fixed it
there,
but 'mvn clean' doesn't here.

My situation: I editied
tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'. My changes didn't take, so I did a 'mvn
clean' then
a 'mvn install'. Changes still aren't picked up.

I suspect it's the cached intermediate file at
tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem. It isn't deleted by a clean.

[INFO]

[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]

[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:
C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld

Re: Maven Build (Ongoing Work Thread)

Volker,

Good point.  I didn't realize you could put resources directly into
the target dir during plugin execution.  I made the change you
suggested and now the TLD's are always cleaned up properly.

Sean

On 1/2/06, Volker Weber [EMAIL PROTECTED] wrote:
 Hi,

 IMHO there should no created artifacts outside of the target directory.

 AFAIK the tlds are created ?

 Everything in target is removed on 'mvn clean'.

 In tobago we have the created tobago.tld in 'target/classes/META-INF/...'.

 Regards
   Volker

 Martin Marinschek wrote:
  Ok, I just refactored the resources directory into a:
 
  resources-tld - all tld files wander into this one
  resources-facesconfig - the config files are situated there and
  resources - for all other (normal) stuff
 
  this might also make it easier to adopt maven-clean; you'd only need
  to throw away everything in resources-tld.
 
 --
 Don't answer to From: address!
 Mail to this account are droped if not recieved via mailinglist.
 To contact me direct create the mail address by
 concatenating my forename to my senders domain.

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread John Fallows

Devs,On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Changes to the TLD files don't seem to be being picked up at build
time; this was a problem in the Ant build as well but 'ant clean'
fixed it there, but 'mvn clean' doesn't here.My situation: I editied tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'. My changes didn't take, so I did a 'mvn
clean' then a 'mvn install'. Changes still aren't picked up.
I suspect it's the cached intermediate file at tomahawk\src\main\resources\META-INF\tomahawk.tld that's causing the problem. It isn't deleted by a clean.[INFO] 
[INFO] Building Tomahawk[INFO] task-segment: [install][INFO] [INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date: C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld

All generated files should live in the target subdirectory, including generated resources such as .tld files.

In ADF Faces we merge together a base .tld from
src/main/conf/META-INF/xxx-base.tld with other metadata to generate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld, and the
plugin automatically adds target/[plugin-name]src/main/resources to the
resource root set (similar to java source path for javac).
When the IDE projects are generated - we use JDeveloper :-) - both the
xxx-base.tld and the xxx.tld files are visible in the merged resources
tree view. When either the xxx-base.tld file or other relevant
metadata is changed, we re-run mvn generate-resources to regenerate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld, without
needing to do a clean build.

Since src/main/resources and target/[plugin-name]/src/main/resources
are both registered as resource roots, but src/main/conf is not, then
the xxx-base.tld is not included in the JAR, but xxx.tld is included,
as desired.

Kind Regards,
John Fallows.
-- Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044

Re: Maven Build (Ongoing Work Thread)

The build doesn't run on my machine anymore - ok, it runs, but the tld
files are not created anymore.

The tld's cannot be created, as the target/classes/META-INF directory
doesn't exist.

Solution anyone?

regards,

Martin

On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:
 Devs,

 On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Changes to the TLD files don't seem to be being picked up at build time;
 this was a problem in the Ant build as well but 'ant clean' fixed it there,
 but 'mvn clean' doesn't here.
 
  My situation:  I editied
 tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
 and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
 a 'mvn install'.  Changes still aren't picked up.
 
  I suspect it's the cached intermediate file at
 tomahawk\src\main\resources\META-INF\tomahawk.tld that's
 causing the problem.  It isn't deleted by a clean.
 
  [INFO]
 
  [INFO] Building Tomahawk
  [INFO]task-segment: [install]
  [INFO]
 
  [INFO] [xslt:transform {execution: default}]
  [INFO] # of XML files: 1
  [INFO] file up-to-date:
 C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld
 
 

 All generated files should live in the target subdirectory, including
 generated resources such as .tld files.

  In ADF Faces we merge together a base .tld from
 src/main/conf/META-INF/xxx-base.tld with other metadata to generate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 and the plugin automatically adds
 target/[plugin-name]src/main/resources to the resource root
 set (similar to java source path for javac).

  When the IDE projects are generated - we use JDeveloper :-) - both the
 xxx-base.tld and the xxx.tld files are visible in the merged resources tree
 view.  When either the xxx-base.tld file or other relevant metadata is
 changed, we re-run mvn generate-resources to regenerate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 without needing to do a clean build.

  Since src/main/resources and
 target/[plugin-name]/src/main/resources are both registered
 as resource roots, but src/main/conf is not, then the xxx-base.tld is not
 included in the JAR, but xxx.tld is included, as desired.

  Kind Regards,
  John Fallows.

 --
 Author Pro JSF and Ajax: Building Rich Internet Components
 http://www.apress.com/book/bookDisplay.html?bID=10044


--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread Bernd Bohmann


Hello Martin,

the xslt-maven-plugin doesn't create destDir if not exists.

Please apply the patch:

Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
===
--- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision 1181)
+++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
@@ -116,6 +116,10 @@
 {
 destFileName = destFileName.replaceAll( 
fileNameRegex, fileNameReplacement );

 }
+   if( !destDir.exists() )
+   {
+   destDir.mkdirs();
+   }   
 File destFile = new File( destDir, destFileName );

 if ( destFile.exists()  srcFile.lastModified()  
destFile.lastModified() )



Bernd

Martin Marinschek schrieb:

The build doesn't run on my machine anymore - ok, it runs, but the tld
files are not created anymore.

The tld's cannot be created, as the target/classes/META-INF directory
doesn't exist.

Solution anyone?

regards,

Martin

On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:


Devs,

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


Changes to the TLD files don't seem to be being picked up at build time;


this was a problem in the Ant build as well but 'ant clean' fixed it there,
but 'mvn clean' doesn't here.


My situation:  I editied


tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
a 'mvn install'.  Changes still aren't picked up.


I suspect it's the cached intermediate file at


tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem.  It isn't deleted by a clean.


[INFO]





[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]





[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:


C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld




All generated files should live in the target subdirectory, including
generated resources such as .tld files.

In ADF Faces we merge together a base .tld from
src/main/conf/META-INF/xxx-base.tld with other metadata to generate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
and the plugin automatically adds
target/[plugin-name]src/main/resources to the resource root
set (similar to java source path for javac).

When the IDE projects are generated - we use JDeveloper :-) - both the
xxx-base.tld and the xxx.tld files are visible in the merged resources tree
view.  When either the xxx-base.tld file or other relevant metadata is
changed, we re-run mvn generate-resources to regenerate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
without needing to do a clean build.

Since src/main/resources and
target/[plugin-name]/src/main/resources are both registered
as resource roots, but src/main/conf is not, then the xxx-base.tld is not
included in the JAR, but xxx.tld is included, as desired.

Kind Regards,
John Fallows.

--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
===
--- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java	(Revision 1181)
+++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java	(Arbeitskopie)
@@ -116,6 +116,10 @@
 {
 destFileName = destFileName.replaceAll( fileNameRegex, fileNameReplacement );
 }
+		if( !destDir.exists() ) 
+		{
+		destDir.mkdirs();
+		}	
 File destFile = new File( destDir, destFileName );
 
 if ( destFile.exists()  srcFile.lastModified()  destFile.lastModified() )

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread John Fallows

Hey Martin,
On 1/2/06, Martin Marinschek 
[EMAIL PROTECTED] wrote:The build doesn't run on my machine anymore - ok, it runs, but the tld
files are not created anymore.The tld's cannot be created, as the target/classes/META-INF directorydoesn't exist.Solution anyone?
The plugin that creates the tlds should also ensure that the output
directory exists. This is good practice for Maven2 plugins in
general.



In addition, that plugin should be running during the
generate-resources phase, the output directory should be
target/[plugin-name]/src/main/resources (or similar), and the output
directory should be added as a dynamic resource root on the
MavenProject object.

Kind Regards,
John Fallows.
On 1/2/06, John Fallows 

[EMAIL PROTECTED] wrote: Devs, On 1/1/06, [EMAIL PROTECTED] 
[EMAIL PROTECTED] wrote:  Changes to the TLD files don't seem to be being picked up at build time;
 this was a problem in the Ant build as well but 'ant clean' fixed it there, but 'mvn clean' doesn't here.   My situation:I editied tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
 and ran 'mvn install'.My changes didn't take, so I did a 'mvn clean' then a 'mvn install'.Changes still aren't picked up.   I suspect it's the cached intermediate file at tomahawk\src\main\resources\META-INF\tomahawk.tld that's
 causing the problem.It isn't deleted by a clean.   [INFO]   [INFO] Building Tomahawk  [INFO]task-segment: [install]
  [INFO]   [INFO] [xslt:transform {execution: default}]  [INFO] # of XML files: 1  [INFO] file up-to-date:
 C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld   All generated files should live in the target subdirectory, including
 generated resources such as .tld files.In ADF Faces we merge together a base .tld from src/main/conf/META-INF/xxx-base.tld with other metadata to generate target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 and the plugin automatically adds target/[plugin-name]src/main/resources to the resource root set (similar to java source path for javac).When the IDE projects are generated - we use JDeveloper :-) - both the
 xxx-base.tld and the xxx.tld files are visible in the merged resources tree view.When either the xxx-base.tld file or other relevant metadata is changed, we re-run mvn generate-resources to regenerate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld, without needing to do a clean build.Since src/main/resources and target/[plugin-name]/src/main/resources are both registered
 as resource roots, but src/main/conf is not, then the xxx-base.tld is not included in the JAR, but xxx.tld is included, as desired.Kind Regards,John Fallows. --
 Author Pro JSF and Ajax: Building Rich Internet Components http://www.apress.com/book/bookDisplay.html?bID=10044
--
http://www.irian.atYour JSF powerhouse -JSF Consulting, Development andCourses in English and GermanProfessional Support for Apache MyFaces-- 

Author Pro JSF and Ajax: Building Rich Internet Componentshttp://www.apress.com/book/bookDisplay.html?bID=10044

Re: Maven Build (Ongoing Work Thread)

You beat me to the patch :-)  Can you submit this to codehaus in their
JIRA so eventually it makes it into the real source code?

Regards,

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 Hello Martin,

 the xslt-maven-plugin doesn't create destDir if not exists.

 Please apply the patch:

 Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
 ===
 --- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision 1181)
 +++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
 @@ -116,6 +116,10 @@
   {
   destFileName = destFileName.replaceAll(
 fileNameRegex, fileNameReplacement );
   }
 +   if( !destDir.exists() )
 +   {
 +   destDir.mkdirs();
 +   }
   File destFile = new File( destDir, destFileName );

   if ( destFile.exists()  srcFile.lastModified() 
 destFile.lastModified() )


 Bernd

 Martin Marinschek schrieb:
  The build doesn't run on my machine anymore - ok, it runs, but the tld
  files are not created anymore.
 
  The tld's cannot be created, as the target/classes/META-INF directory
  doesn't exist.
 
  Solution anyone?
 
  regards,
 
  Martin
 
  On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:
 
 Devs,
 
 On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 Changes to the TLD files don't seem to be being picked up at build time;
 
 this was a problem in the Ant build as well but 'ant clean' fixed it there,
 but 'mvn clean' doesn't here.
 
 My situation:  I editied
 
 tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
 and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
 a 'mvn install'.  Changes still aren't picked up.
 
 I suspect it's the cached intermediate file at
 
 tomahawk\src\main\resources\META-INF\tomahawk.tld that's
 causing the problem.  It isn't deleted by a clean.
 
 [INFO]
 
 
 
 [INFO] Building Tomahawk
 [INFO]task-segment: [install]
 [INFO]
 
 
 
 [INFO] [xslt:transform {execution: default}]
 [INFO] # of XML files: 1
 [INFO] file up-to-date:
 
 C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld
 
 
 All generated files should live in the target subdirectory, including
 generated resources such as .tld files.
 
  In ADF Faces we merge together a base .tld from
 src/main/conf/META-INF/xxx-base.tld with other metadata to generate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 and the plugin automatically adds
 target/[plugin-name]src/main/resources to the resource root
 set (similar to java source path for javac).
 
  When the IDE projects are generated - we use JDeveloper :-) - both the
 xxx-base.tld and the xxx.tld files are visible in the merged resources tree
 view.  When either the xxx-base.tld file or other relevant metadata is
 changed, we re-run mvn generate-resources to regenerate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 without needing to do a clean build.
 
  Since src/main/resources and
 target/[plugin-name]/src/main/resources are both registered
 as resource roots, but src/main/conf is not, then the xxx-base.tld is not
 included in the JAR, but xxx.tld is included, as desired.
 
  Kind Regards,
  John Fallows.
 
 --
 Author Pro JSF and Ajax: Building Rich Internet Components
 http://www.apress.com/book/bookDisplay.html?bID=10044
 
 
 
  --
 
  http://www.irian.at
 
  Your JSF powerhouse -
  JSF Consulting, Development and
  Courses in English and German
 
  Professional Support for Apache MyFaces
 

 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

I'm making progress on this.  I just checked in a fix that addresses
the missing resource bundle issue.  All I had to do was create
test/resources/Messages.properties.  I'm liking Maven more and more
...

There are still problems with the commons tests that I am trying to
resolve.  NOTE: These are errors as opposed to test failures.  We can
address the test failures later.

Sean

On 1/1/06, Sean Schofield [EMAIL PROTECTED] wrote:
 There is a problem with the commons build.  Apparently the
 MessageUtilsTest has a dependency on MyFacesImpl (because it loads
 specific messages from the resource bundle.)  I think those tests can
 probably be rewritten to use a custom message bundle so that there is
 no dependency on the impl subproject.

 Making commons dependent on impl is not an option because impl already
 depends on commons (so Maven complains about a circular dependency.)

 Sean

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread Bernd Bohmann


Done

http://jira.codehaus.org/browse/MOJO-203

Sean Schofield schrieb:

You beat me to the patch :-)  Can you submit this to codehaus in their
JIRA so eventually it makes it into the real source code?

Regards,

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:


Hello Martin,

the xslt-maven-plugin doesn't create destDir if not exists.

Please apply the patch:

Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
===
--- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision 1181)
+++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
@@ -116,6 +116,10 @@
 {
 destFileName = destFileName.replaceAll(
fileNameRegex, fileNameReplacement );
 }
+   if( !destDir.exists() )
+   {
+   destDir.mkdirs();
+   }
 File destFile = new File( destDir, destFileName );

 if ( destFile.exists()  srcFile.lastModified() 
destFile.lastModified() )


Bernd

Martin Marinschek schrieb:


The build doesn't run on my machine anymore - ok, it runs, but the tld
files are not created anymore.

The tld's cannot be created, as the target/classes/META-INF directory
doesn't exist.

Solution anyone?

regards,

Martin

On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:



Devs,

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:



Changes to the TLD files don't seem to be being picked up at build time;


this was a problem in the Ant build as well but 'ant clean' fixed it there,
but 'mvn clean' doesn't here.



My situation:  I editied


tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
a 'mvn install'.  Changes still aren't picked up.



I suspect it's the cached intermediate file at


tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem.  It isn't deleted by a clean.



[INFO]






[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]






[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:


C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld


All generated files should live in the target subdirectory, including
generated resources such as .tld files.

In ADF Faces we merge together a base .tld from
src/main/conf/META-INF/xxx-base.tld with other metadata to generate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
and the plugin automatically adds
target/[plugin-name]src/main/resources to the resource root
set (similar to java source path for javac).

When the IDE projects are generated - we use JDeveloper :-) - both the
xxx-base.tld and the xxx.tld files are visible in the merged resources tree
view.  When either the xxx-base.tld file or other relevant metadata is
changed, we re-run mvn generate-resources to regenerate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
without needing to do a clean build.

Since src/main/resources and
target/[plugin-name]/src/main/resources are both registered
as resource roots, but src/main/conf is not, then the xxx-base.tld is not
included in the JAR, but xxx.tld is included, as desired.

Kind Regards,
John Fallows.

--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333








--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

Dennis,

I'm still having issues with the client state encryption tests.  Can
you find a way to make them run in Maven?

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 Done

 http://jira.codehaus.org/browse/MOJO-203

 Sean Schofield schrieb:
  You beat me to the patch :-)  Can you submit this to codehaus in their
  JIRA so eventually it makes it into the real source code?
 
  Regards,
 
  Sean
 
  On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
 
 Hello Martin,
 
 the xslt-maven-plugin doesn't create destDir if not exists.
 
 Please apply the patch:
 
 Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
 ===
 --- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision 1181)
 +++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
 @@ -116,6 +116,10 @@
   {
   destFileName = destFileName.replaceAll(
 fileNameRegex, fileNameReplacement );
   }
 +   if( !destDir.exists() )
 +   {
 +   destDir.mkdirs();
 +   }
   File destFile = new File( destDir, destFileName );
 
   if ( destFile.exists()  srcFile.lastModified() 
 destFile.lastModified() )
 
 
 Bernd
 
 Martin Marinschek schrieb:
 
 The build doesn't run on my machine anymore - ok, it runs, but the tld
 files are not created anymore.
 
 The tld's cannot be created, as the target/classes/META-INF directory
 doesn't exist.
 
 Solution anyone?
 
 regards,
 
 Martin
 
 On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:
 
 
 Devs,
 
 On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 
 Changes to the TLD files don't seem to be being picked up at build time;
 
 this was a problem in the Ant build as well but 'ant clean' fixed it 
 there,
 but 'mvn clean' doesn't here.
 
 
 My situation:  I editied
 
 tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
 and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' 
 then
 a 'mvn install'.  Changes still aren't picked up.
 
 
 I suspect it's the cached intermediate file at
 
 tomahawk\src\main\resources\META-INF\tomahawk.tld that's
 causing the problem.  It isn't deleted by a clean.
 
 
 [INFO]
 
 
 
 
 [INFO] Building Tomahawk
 [INFO]task-segment: [install]
 [INFO]
 
 
 
 
 [INFO] [xslt:transform {execution: default}]
 [INFO] # of XML files: 1
 [INFO] file up-to-date:
 
 C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld
 
 
 All generated files should live in the target subdirectory, including
 generated resources such as .tld files.
 
 In ADF Faces we merge together a base .tld from
 src/main/conf/META-INF/xxx-base.tld with other metadata to generate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 and the plugin automatically adds
 target/[plugin-name]src/main/resources to the resource root
 set (similar to java source path for javac).
 
 When the IDE projects are generated - we use JDeveloper :-) - both the
 xxx-base.tld and the xxx.tld files are visible in the merged resources 
 tree
 view.  When either the xxx-base.tld file or other relevant metadata is
 changed, we re-run mvn generate-resources to regenerate
 target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
 without needing to do a clean build.
 
 Since src/main/resources and
 target/[plugin-name]/src/main/resources are both registered
 as resource roots, but src/main/conf is not, then the xxx-base.tld is not
 included in the JAR, but xxx.tld is included, as desired.
 
 Kind Regards,
 John Fallows.
 
 --
 Author Pro JSF and Ajax: Building Rich Internet Components
 http://www.apress.com/book/bookDisplay.html?bID=10044
 
 
 
 --
 
 http://www.irian.at
 
 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German
 
 Professional Support for Apache MyFaces
 
 
 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333
 
 
 
 
 

 --
 Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
 Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
 phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333

Re: Maven Build (Ongoing Work Thread)

2006-01-02 Thread Bernd Bohmann


Hello Sean,

I think the current version of the surefire-plugin doesn't support the 
forking mode. This is fixed in the latest not yet released version.
I see the StateUtils are using a static block for loading the 
properties. I don't know how this can work if your are in one JVM?


I think you have two options:
Disable the test until the new version of the surefire plugin is 
released or change the test to a mock version.


Any comments?

The StateUtilsAES_CBCTestCase doesn't work in my environment.
A missing dependency or wrong configuration?
I get following error:

java.security.InvalidKeyException: Illegal key size


Bernd

Sean Schofield schrieb:

Dennis,

I'm still having issues with the client state encryption tests.  Can
you find a way to make them run in Maven?

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:


Done

http://jira.codehaus.org/browse/MOJO-203

Sean Schofield schrieb:


You beat me to the patch :-)  Can you submit this to codehaus in their
JIRA so eventually it makes it into the real source code?

Regards,

Sean

On 1/2/06, Bernd Bohmann [EMAIL PROTECTED] wrote:



Hello Martin,

the xslt-maven-plugin doesn't create destDir if not exists.

Please apply the patch:

Index: src/main/java/org/codehaus/mojo/xslt/XsltMojo.java
===
--- src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Revision 1181)
+++ src/main/java/org/codehaus/mojo/xslt/XsltMojo.java  (Arbeitskopie)
@@ -116,6 +116,10 @@
{
destFileName = destFileName.replaceAll(
fileNameRegex, fileNameReplacement );
}
+   if( !destDir.exists() )
+   {
+   destDir.mkdirs();
+   }
File destFile = new File( destDir, destFileName );

if ( destFile.exists()  srcFile.lastModified() 
destFile.lastModified() )


Bernd

Martin Marinschek schrieb:



The build doesn't run on my machine anymore - ok, it runs, but the tld
files are not created anymore.

The tld's cannot be created, as the target/classes/META-INF directory
doesn't exist.

Solution anyone?

regards,

Martin

On 1/2/06, John Fallows [EMAIL PROTECTED] wrote:




Devs,

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:




Changes to the TLD files don't seem to be being picked up at build time;


this was a problem in the Ant build as well but 'ant clean' fixed it there,
but 'mvn clean' doesn't here.




My situation:  I editied


tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
a 'mvn install'.  Changes still aren't picked up.




I suspect it's the cached intermediate file at


tomahawk\src\main\resources\META-INF\tomahawk.tld that's
causing the problem.  It isn't deleted by a clean.




[INFO]







[INFO] Building Tomahawk
[INFO]task-segment: [install]
[INFO]







[INFO] [xslt:transform {execution: default}]
[INFO] # of XML files: 1
[INFO] file up-to-date:


C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld


All generated files should live in the target subdirectory, including
generated resources such as .tld files.

In ADF Faces we merge together a base .tld from
src/main/conf/META-INF/xxx-base.tld with other metadata to generate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
and the plugin automatically adds
target/[plugin-name]src/main/resources to the resource root
set (similar to java source path for javac).

When the IDE projects are generated - we use JDeveloper :-) - both the
xxx-base.tld and the xxx.tld files are visible in the merged resources tree
view.  When either the xxx-base.tld file or other relevant metadata is
changed, we re-run mvn generate-resources to regenerate
target/[plugin-name]/src/main/resources/META-INF/xxx.tld,
without needing to do a clean build.

Since src/main/resources and
target/[plugin-name]/src/main/resources are both registered
as resource roots, but src/main/conf is not, then the xxx-base.tld is not
included in the JAR, but xxx.tld is included, as desired.

Kind Regards,
John Fallows.

--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173 8839471, fax: +49 441 4082333







--
Dipl.-Ing. Bernd Bohmann - Atanion GmbH - Software Development
Bismarckstr. 13, 26122 Oldenburg, http://www.atanion.com
phone: +49 441 4082312, mobile: +49 173

Re: Maven Build (Ongoing Work Thread)

2006-01-01 Thread Bruno Aranda

Yes, I also found the problems with that test (although I haven't
search why failed). Till now, I've been just building with:

mvn -Dmaven.test.failure.ignore=true install

to ignore if tests failed...

Maybe, we could comment that test in the meanwhile, while someone
looks for the solution,

Bruno

2006/1/1, Sean Schofield [EMAIL PROTECTED]:
 There is a problem with the commons build.  Apparently the
 MessageUtilsTest has a dependency on MyFacesImpl (because it loads
 specific messages from the resource bundle.)  I think those tests can
 probably be rewritten to use a custom message bundle so that there is
 no dependency on the impl subproject.

 Making commons dependent on impl is not an option because impl already
 depends on commons (so Maven complains about a circular dependency.)

 Sean

Re: Maven Build (Ongoing Work Thread)

I'm getting compile errors when building from the tip (revision 360573). Environment is XP SP2 with mvn 2.0.1 freshly installed, and a completely clean checkout.--C:\work\workspace\myfaces-current-postreorg\buildmvn install
[INFO] Scanning for projects...[INFO] Reactor build order:[INFO] MyFaces[INFO] MyFaces API[INFO] MyFaces Commons[INFO] MyFaces Impl[INFO] Tomahawk[INFO] MyFaces Sandbox[INFO] MyFaces Examples
[INFO] MyFaces Examples: Blank[INFO] MyFaces Examples: Simple[INFO] MyFaces Examples: Sandbox[INFO] MyFaces Examples: Tiles[INFO] MyFaces Examples: WAP[INFO] 
[INFO] Building MyFaces[INFO] task-segment: [install][INFO] [INFO] [install:install][INFO] Installing C:\work\workspace\myfaces-current-postreorg\build\pom.xml to C:\Documents and Settings\Steve Peterson\.m2\reposi
tory\myfaces\apache\org\myfaces\1.1.2-SNAPSHOT\myfaces-1.1.2-SNAPSHOT.pom[INFO] [INFO] Building MyFaces API[INFO] task-segment: [install]
[INFO] [INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:compile][INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources][INFO] Using default encoding to copy filtered resources.[INFO] [compiler:testCompile][INFO] Nothing to compile - all classes are up to date[INFO] [surefire:test][INFO] Setting reports dir: C:\work\workspace\myfaces-current-postreorg\build\..\api\target/surefire-reports
---T E S T S---[surefire] Running javax.faces.application.FacesMessageTest[surefire] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 
0.032 sec[surefire] Running javax.faces.application.StateManagerTest[surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.312 sec[surefire] Running javax.faces.component.UIComponentBaseTest[surefire] Tests run: 45, Failures: 0, Errors: 0, Time elapsed: 
0.047 sec[surefire] Running javax.faces.component._AttachedListStateWrapperTest[surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec[surefire] Running javax.faces.component._AttachedStateWrapperTest
[surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0 sec[surefire] Running javax.faces.FacesExceptionTest[surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.015 sec[surefire] Running 
javax.faces.FactoryFinderTest[surefire] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.016 secResults :[surefire] Tests run: 82, Failures: 0, Errors: 0[INFO] [jar:jar][INFO] Building jar: C:\work\workspace\myfaces-current-postreorg\build\..\api\target\myfaces-
api-1.1.2-SNAPSHOT.jar[INFO] [install:install][INFO] Installing C:\work\workspace\myfaces-current-postreorg\build\..\api\target\myfaces-api-1.1.2-SNAPSHOT.jar to C:\Documents and Settings\Steve Peterson\.m2\repository\myfaces\apache\org\myfaces-api\1.1.2-SNAPSHOT\myfaces-
api-1.1.2-SNAPSHOT.jar[INFO] [INFO] Building MyFaces Commons[INFO] task-segment: [install][INFO] 
[INFO] [resources:resources][INFO] Using default encoding to copy filtered resources.Downloading: http://repo1.maven.org/maven2/myfaces/apache/org/myfaces-api/1.1.2/myfaces-api-1.1.2.pom
[WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2)[INFO] [compiler:compile]Compiling 83 source files to C:\work\workspace\myfaces-current-postreorg\build\..\commons\target\classes
[INFO] [ERROR] BUILD FAILURE[INFO] [INFO] Compilation failure
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[4,34] packageorg.apache.commons.logging does not existC:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[5,34] package
org.apache.commons.logging does not existC:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[70,25] cannotresolve symbolsymbol : class Log
location: class org.apache.myfaces.util.StateUtilsC:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentBodyTagBase.java:[21,34] package org.apache.commons.logging
 does not existC:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentBodyTagBase.java:[22,34] package org.apache.commons.logging does not exist

Re: Maven Build (Ongoing Work Thread)

2006-01-01 Thread Wendy Smoak

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 I'm getting compile errors when building from the tip (revision 360573).
 Environment is XP SP2 with mvn 2.0.1 freshly installed, and a completely
 clean checkout.
 cannot
 resolve symbol
 symbol  : class Log
 location: class org.apache.myfaces.util.StateUtils

I was getting that, too.  Bruno just (in r360574) added a dependency
on commons-logging to the myfaces-commons pom.  That should fix the
compilation, but there may still be problems with the tests.  If so,
you can use his suggestion of -Dmaven.test.failure.ignore=true to get
past that for now.

--
Wendy

Re: Maven Build (Ongoing Work Thread)

2006-01-01 Thread Matthias Wessendorf

The Log* related stuff was caused by a buggy commons/pom.xml

But, you still have to check the a maven plugin (source) and install
it to your local repo
(http://www.mail-archive.com/dev@myfaces.apache.org/msg08125.html)

mvn install

-Matthias

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 I'm getting compile errors when building from the tip (revision 360573).
 Environment is XP SP2 with mvn 2.0.1 freshly installed, and a completely
 clean checkout.

 --

 C:\work\workspace\myfaces-current-postreorg\buildmvn
 install
 [INFO] Scanning for projects...
 [INFO] Reactor build order:
 [INFO]   MyFaces
 [INFO]   MyFaces API
 [INFO]   MyFaces Commons
 [INFO]   MyFaces Impl
 [INFO]   Tomahawk
 [INFO]   MyFaces Sandbox
 [INFO]   MyFaces Examples
 [INFO]   MyFaces Examples: Blank
 [INFO]   MyFaces Examples: Simple
 [INFO]   MyFaces Examples: Sandbox
 [INFO]   MyFaces Examples: Tiles
 [INFO]   MyFaces Examples: WAP
 [INFO]
 
 [INFO] Building MyFaces
 [INFO]task-segment: [install]
 [INFO]
 
 [INFO] [install:install]
 [INFO] Installing
 C:\work\workspace\myfaces-current-postreorg\build\pom.xml
 to C:\Documents and Settings\Steve Peterson\.m2\reposi
 tory\myfaces\apache\org\myfaces\1.1.2-SNAPSHOT\myfaces-1.1.2-SNAPSHOT.pom
 [INFO]
 
 [INFO] Building MyFaces API
 [INFO]task-segment: [install]
 [INFO]
 
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] Nothing to compile - all classes are up to date
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] Nothing to compile - all classes are up to date
 [INFO] [surefire:test]
 [INFO] Setting reports dir:
 C:\work\workspace\myfaces-current-postreorg\build\..\api\target/surefire-reports

 ---
  T E S T S
 ---
 [surefire] Running javax.faces.application.FacesMessageTest
 [surefire] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.032 sec
 [surefire] Running javax.faces.application.StateManagerTest
 [surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.312 sec
 [surefire] Running
 javax.faces.component.UIComponentBaseTest
 [surefire] Tests run: 45, Failures: 0, Errors: 0, Time elapsed: 0.047 sec
 [surefire] Running
 javax.faces.component._AttachedListStateWrapperTest
 [surefire] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec
 [surefire] Running
 javax.faces.component._AttachedStateWrapperTest
 [surefire] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0 sec
 [surefire] Running javax.faces.FacesExceptionTest
 [surefire] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.015 sec
 [surefire] Running javax.faces.FactoryFinderTest
 [surefire] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.016 sec

 Results :
 [surefire] Tests run: 82, Failures: 0, Errors: 0

 [INFO] [jar:jar]
 [INFO] Building jar:
 C:\work\workspace\myfaces-current-postreorg\build\..\api\target\myfaces-
 api-1.1.2-SNAPSHOT.jar
 [INFO] [install:install]
 [INFO] Installing
 C:\work\workspace\myfaces-current-postreorg\build\..\api\target\myfaces-api-1.1.2-SNAPSHOT.jar
 to C:\Documents a
 nd Settings\Steve
 Peterson\.m2\repository\myfaces\apache\org\myfaces-api\1.1.2-SNAPSHOT\myfaces-
 api-1.1.2-SNAPSHOT.jar
 [INFO]
 
 [INFO] Building MyFaces Commons
 [INFO]task-segment: [install]
 [INFO]
 
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 Downloading:
 http://repo1.maven.org/maven2/myfaces/apache/org/myfaces-api/1.1.2/myfaces-api-1.1.2.pom
 [WARNING] Unable to get resource from repository central
 (http://repo1.maven.org/maven2)
 [INFO] [compiler:compile]
 Compiling 83 source files to
 C:\work\workspace\myfaces-current-postreorg\build\..\commons\target\classes
 [INFO]
 
 [ERROR] BUILD FAILURE
 [INFO]
 
 [INFO] Compilation failure

 C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[4,34]
 package
 org.apache.commons.logging does not exist

 C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[5,34]
 package
 org.apache.commons.logging does not exist

Re: Maven Build (Ongoing Work Thread)

Cool. Is there a wiki page going yet on how to get a source build working? If not I'll start one and put my notes on there.Steve

Re: Maven Build (Ongoing Work Thread)

2006-01-01 Thread Wendy Smoak

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

 Cool.  Is there a wiki page going yet on how to get a source build
 working?  If not I'll start one and put my notes on there.

How about...
   http://wiki.apache.org/myfaces/Building_With_Maven

--
Wendy

Re: Maven Build (Ongoing Work Thread)

The build ran with the changes suggested. Thanks!I updated http://wiki.apache.org/myfaces/Building_With_Maven
 with the steps I took.

Re: Maven Build (Ongoing Work Thread)

Does it make sense for http://myfaces.apache.org/buildhowto.html to have a link to the wiki until it's updated?

Re: Maven Build (Ongoing Work Thread)

Probably but the website uses Ant to build and that's now broken ...
If it continues to be a problem maybe we will change it manually.

@everyone: feel free to update that wiki!

Sean

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Does it make sense for
 http://myfaces.apache.org/buildhowto.html to have a link to
 the wiki until it's updated?

Re: Maven Build (Ongoing Work Thread)

@Bruno:

Some feedback on your website stuff ... First of all, thanks for all
of the hard work!  You've added a ton of stuff here.  I haven't
checked out everything but you did a nice job porting over the
documentation.  I also like how you have enhanced some of the default
Maven settings so the site looks a little more interesting.

I'm not too crazy about the new Easter Island graphic.  I would
stick with the current ASCII like face we have now ...

Also, I don't like a few of the colors.  My suggestion would be to go
back to the dark blue banner and existing Apache MyFaces label
graphic that we have.  We probably don't want to keep dark blue
forever and I'm ok with a lighter color scheme at some point but I
like the old colors better then the new.

Nice job though.  Its looking good.  And we have a lot of people
helping out now so we should get through this pretty quickly!

Sean

On 1/1/06, Sean Schofield [EMAIL PROTECTED] wrote:
 Probably but the website uses Ant to build and that's now broken ...
 If it continues to be a problem maybe we will change it manually.

 @everyone: feel free to update that wiki!

 Sean

 On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Does it make sense for
  http://myfaces.apache.org/buildhowto.html to have a link to
  the wiki until it's updated?

Re: Maven Build (Ongoing Work Thread)

The sample app seems to be working fine with the build I ran, using Tomcat 5.5.12 on JDK 1.5.

Re: Maven Build (Ongoing Work Thread)

One thing that was nice about the old build structure is that, after your first build, you ended up with a nice lib directory off of the root of your project that you could use in your IDE to get the classpath set up. Is there a way to get the same thing going with the new structure?

Re: Maven Build (Ongoing Work Thread)

If you use mvn install it will install the jars in the maven
repository of your home dir.  So I set up libraries that point to the
install location and just run mvn install.

Sean

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 One thing that was nice about the old build structure is that, after your
 first build, you ended up with a nice lib directory off of the root of your
 project that you could use in your IDE to get the classpath set up.  Is
 there a way to get the same thing going with the new structure?

Re: Maven Build (Ongoing Work Thread)

2006-01-01 Thread Wendy Smoak

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 One thing that was nice about the old build structure is that, after your
 first build, you ended up with a nice lib directory off of the root of your
 project that you could use in your IDE to get the classpath set up.  Is
 there a way to get the same thing going with the new structure?

What IDE are you using?  There may be a plugin available to set up the
project files, for example:

/svn/myfaces/current/build
$ mvn idea:idea

--
Wendy

Re: Maven Build (Ongoing Work Thread)

Apropros IDEs, a word of caution for IntelliJ-users:

I checked out in IntelliJ, and obviously all those new classes got the
internal subversion client confused. So if something doesn't work in
your Maven-Build, make sure you try an svn-update on the command line.

regards,

Martin

On 1/2/06, Wendy Smoak [EMAIL PROTECTED] wrote:
 On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  One thing that was nice about the old build structure is that, after your
  first build, you ended up with a nice lib directory off of the root of your
  project that you could use in your IDE to get the classpath set up.  Is
  there a way to get the same thing going with the new structure?

 What IDE are you using?  There may be a plugin available to set up the
 project files, for example:

 /svn/myfaces/current/build
 $ mvn idea:idea

 --
 Wendy



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

Thanks for the pointer. I saw the eclipse:eclipse plugin but like to do things the old fashioned way the first time to understand what's going on.Sean, not sure what you're meaning by your comment. Are you suggesting adding each of the libraries from ~/.m2/repository/... to the project?

RE: Maven Build (Ongoing Work Thread)

2006-01-01 Thread Korhonen, Kalle





  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] Subject: Re: Maven Build (Ongoing Work 
  Thread)
  Thanks for the pointer. I saw the eclipse:eclipse plugin but like 
  to do things the old fashioned way the first time to understand what's going 
  on.Sean, not sure what you're meaning by your comment. Are you 
  suggesting adding each of the libraries from ~/.m2/repository/... to the 
  project?
  
eclipse:eclipse would do just that -create Eclipse 
M2variable, then create .classpath file with entries pointing to Maven's 
repository. That's one of the main concepts in it; that you have the thirdparty 
libs in only one place.

Kalle

Re: Maven Build (Ongoing Work Thread)

I checked in a few changes to the style (changes were made to only the
tomahawk project.)  Suggestion: lets modify just that project for now
(in terms of look and feel) until we are happy.

I wonder if there is an easy way to share website resources in maven? 
I don't think we should have 10 copies of the stylesheets, etc. per
project.  We can use externals but I hesitate to do that b/c they are
a PITA when you are branching and tagging (the externals don't change
automatically - you have to change them all manually.)

Sean

On 1/1/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Thanks for the pointer.  I saw the eclipse:eclipse plugin but like to do
 things the old fashioned way the first time to understand what's going on.

 Sean, not sure what you're meaning by your comment.  Are you suggesting
 adding each of the libraries from ~/.m2/repository/... to the project?

Re: Maven Build (Ongoing Work Thread)

Changes to the TLD files don't seem to be being picked up at build time; this was a problem in the Ant build as well but 'ant clean' fixed it there, but 'mvn clean' doesn't here.My situation: I editied tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml and ran 'mvn install'. My changes didn't take, so I did a 'mvn clean' then a 'mvn install'. Changes still aren't picked up.
I suspect it's the cached intermediate file at tomahawk\src\main\resources\META-INF\tomahawk.tld that's causing the problem. It isn't deleted by a clean.[INFO] 
[INFO] Building Tomahawk[INFO] task-segment: [install][INFO] [INFO] [xslt:transform {execution: default}][INFO] # of XML files: 1
[INFO] file up-to-date: C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld

Re: Maven Build (Ongoing Work Thread)

Same problem here -

plus I don't find a way to get the current structure up and running in IntelliJ.

Anyone successful so far? Particularly, I don't find a way to include
my tld+faces-config.xml files properly - without loosing e.g. the
standard-faces-config.xml file.

Is there a way to split this up in impl, particularly have

src/main/java
src/main/resource_tld/META-INF/tlds
src/main/resource/rest of resources

plus - shouldn't we rename tomahawk to myfaces-tomahawk - if all other
projects have this name prefix?

regards,

Martin

On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Changes to the TLD files don't seem to be being picked up at build time;
 this was a problem in the Ant build as well but 'ant clean' fixed it there,
 but 'mvn clean' doesn't here.

 My situation:  I editied
 tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
 and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
 a 'mvn install'.  Changes still aren't picked up.

 I suspect it's the cached intermediate file at
 tomahawk\src\main\resources\META-INF\tomahawk.tld that's
 causing the problem.  It isn't deleted by a clean.

 [INFO]
 
 [INFO] Building Tomahawk
 [INFO]task-segment: [install]
 [INFO]
 
 [INFO] [xslt:transform {execution: default}]
 [INFO] # of XML files: 1
 [INFO] file up-to-date:
 C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld




--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)

Ok, I just refactored the resources directory into a:

resources-tld - all tld files wander into this one
resources-facesconfig - the config files are situated there and
resources - for all other (normal) stuff

this might also make it easier to adopt maven-clean; you'd only need
to throw away everything in resources-tld.

I've got that to run in IntelliJ no problem, short instructions as following:

- use mvn idea:idea (thanks Wendy for that hint!) to create a project file
- adopt the dependencies between the created modules as necessary,
- edit myfaces-examples-simple, add as a content-root all
src/main/resources-tld and src/main/resources-facesconfig directories
of impl and tomahawk.
- edit the web-module-settings - make sure to include the correct
libs, and ensure that the copy files to option is enabled for them
(_exclude_ commons-el and jsp2.0.jar - yes, really I've done it again
;)
- add the /META-INF sub-directories of the above-added content-roots
as web-resource-directories, using a path relative to deployment root
of /WEB-INF

it would be great if someone could update

http://wiki.apache.org/myfaces/JetBrains_IntelliJ_IDEA

with a little fleshed out version of this info ;)

regards,

Martin

On 1/2/06, Martin Marinschek [EMAIL PROTECTED] wrote:
 Same problem here -

 plus I don't find a way to get the current structure up and running in 
 IntelliJ.

 Anyone successful so far? Particularly, I don't find a way to include
 my tld+faces-config.xml files properly - without loosing e.g. the
 standard-faces-config.xml file.

 Is there a way to split this up in impl, particularly have

 src/main/java
 src/main/resource_tld/META-INF/tlds
 src/main/resource/rest of resources

 plus - shouldn't we rename tomahawk to myfaces-tomahawk - if all other
 projects have this name prefix?

 regards,

 Martin

 On 1/2/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Changes to the TLD files don't seem to be being picked up at build time;
  this was a problem in the Ant build as well but 'ant clean' fixed it there,
  but 'mvn clean' doesn't here.
 
  My situation:  I editied
  tomahawk/src/main/tld/tomahawk-entities/tomahawk_validate_equal_attributes.xml
  and ran 'mvn install'.  My changes didn't take, so I did a 'mvn clean' then
  a 'mvn install'.  Changes still aren't picked up.
 
  I suspect it's the cached intermediate file at
  tomahawk\src\main\resources\META-INF\tomahawk.tld that's
  causing the problem.  It isn't deleted by a clean.
 
  [INFO]
  
  [INFO] Building Tomahawk
  [INFO]task-segment: [install]
  [INFO]
  
  [INFO] [xslt:transform {execution: default}]
  [INFO] # of XML files: 1
  [INFO] file up-to-date:
  C:\work\workspace\myfaces-current-postreorg\build\..\tomahawk\src\main\resources\META-INF\tomahawk.tld
 
 


 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces



--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Maven Build (Ongoing Work Thread)