You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sean Schofield <se...@gmail.com> on 2006/01/01 23:25:40 UTC
Maven Build (Ongoing Work Thread)
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)
Posted by Sean Schofield <se...@gmail.com>.
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 <se...@gmail.com> 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)
Posted by Sean Schofield <se...@gmail.com>.
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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by John Fallows <jo...@gmail.com>.
Hey Martin,
On 1/2/06, Martin Marinschek < martin.marinschek@gmail.com> 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 directory
> doesn'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 < john.r.fallows@gmail.com> wrote:
> > Devs,
> >
> > On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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
>
--
Author Pro JSF and Ajax: Building Rich Internet Components
http://www.apress.com/book/bookDisplay.html?bID=10044
Re: Maven Build (Ongoing Work Thread)
Posted by Sean Schofield <se...@gmail.com>.
Right that's what I meant. I use tortoise-cvs here at work ;-)
sean
On 1/3/06, John Fallows <jo...@gmail.com> wrote:
> On 1/3/06, Sean Schofield <se...@gmail.com> 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)
Posted by John Fallows <jo...@gmail.com>.
On 1/3/06, Sean Schofield <se...@gmail.com> 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)
Posted by Sean Schofield <se...@gmail.com>.
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 <ma...@gmail.com> 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 <mw...@gmail.com> 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 <se...@gmail.com> 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 <ws...@gmail.com> wrote:
> > > > On 1/3/06, Sean Schofield <se...@gmail.com> 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>
> > > > <groupId>struts</groupId>
> > > > <artifactId>struts-build</artifactId>
> > > > <version>1.3.0-SNAPSHOT</version>
> > > > <relativePath>build/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)
Posted by Travis Reeder <tr...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> ;)
>
> bahh!
>
> Martin no like!
>
> regards,
>
> Martin
>
> On 1/3/06, Bernd Bohmann <be...@atanion.com> 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 <be...@atanion.com> 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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Martin Marinschek <ma...@gmail.com>.
;)
bahh!
Martin no like!
regards,
Martin
On 1/3/06, Bernd Bohmann <be...@atanion.com> 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 <be...@atanion.com> 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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Bill Dudney <bd...@mac.com>.
Hi Matthias,
AFAIK there is no way to make a multi-module maven project into a
single Eclipse project.
I find though once I got over the initial irritation at the multi-
project approach I did not mind so much. Make sure to use a working
set so that you don't always have to look at the list of jar files.
Another thing to take a look at is the Maven2 plugin for Eclipse.
I've been using it for a couple of days and so far so good.
TTFN,
-bd-
On Jan 4, 2006, at 1:05 PM, Matthias Wessendorf wrote:
> Hi,
>
>> 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.
>
> there is no such thing for eclipse w/ maven2 ?
>
> Do I have to *remain* with serveral eclipse projects for MyFaces?
>
> -Matthias
>
>
>
>>
>> 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.
>>
>
>
> --
> 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)
Posted by Bernd Bohmann <be...@atanion.com>.
Sorry,
I think the eclipse plugin is reactor aware.
But I don't know how it is activated.
Maybe this helps:
http://maven.apache.org/guides/mini/guide-ide-eclipse.html
Bernd
Matthias Wessendorf schrieb:
>>See
>>
>>http://maven.apache.org/plugins/maven-eclipse-plugin/
>>
>>mvn eclipse:eclipse
>
>
> he he, yes I saw. I was meaning something like "multi-module" project ;)
>
--
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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
> See
>
> http://maven.apache.org/plugins/maven-eclipse-plugin/
>
> mvn eclipse:eclipse
he he, yes I saw. I was meaning something like "multi-module" project ;)
Re: Maven Build (Ongoing Work Thread)
Posted by Bernd Bohmann <be...@atanion.com>.
See
http://maven.apache.org/plugins/maven-eclipse-plugin/
mvn eclipse:eclipse
Bernd
Matthias Wessendorf schrieb:
> Hi,
>
>
>>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.
>
>
> there is no such thing for eclipse w/ maven2 ?
>
> Do I have to *remain* with serveral eclipse projects for MyFaces?
>
> -Matthias
>
>
>
>
>>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.
>>
>
>
>
> --
> 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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
Hi,
> 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.
there is no such thing for eclipse w/ maven2 ?
Do I have to *remain* with serveral eclipse projects for MyFaces?
-Matthias
>
> 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.
>
--
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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <be...@atanion.com> 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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Volker Weber <us...@weber-oldenburg.de>.
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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <be...@atanion.com> 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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Travis Reeder <tr...@gmail.com>.
I've just checked in some pom changes that add the resources-facesconfig
directories.
Travis
On 1/3/06, Martin Marinschek <ma...@gmail.com> wrote:
>
> 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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Bernd Bohmann <be...@atanion.com>.
.
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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <be...@atanion.com> 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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Sean Schofield <se...@gmail.com>.
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 <ma...@gmail.com> 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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Sean Schofield <se...@gmail.com>.
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 <mw...@gmail.com> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Sean Schofield <se...@gmail.com>.
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 <tr...@gmail.com> 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 <mwessendorf@gmail.com > 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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
bernd,
solved ;)
On 1/3/06, Bernd Bohmann <be...@atanion.com> 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 <se...@gmail.com> 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 <ws...@gmail.com> wrote:
> >>
> >>>On 1/3/06, Sean Schofield <se...@gmail.com> 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>
> >>> <groupId>struts</groupId>
> >>> <artifactId>struts-build</artifactId>
> >>> <version>1.3.0-SNAPSHOT</version>
> >>> <relativePath>build/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)
Posted by Travis Reeder <tr...@gmail.com>.
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 <mw...@gmail.com> 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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <se...@gmail.com> 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 <ws...@gmail.com> wrote:
>>
>>>On 1/3/06, Sean Schofield <se...@gmail.com> 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>
>>> <groupId>struts</groupId>
>>> <artifactId>struts-build</artifactId>
>>> <version>1.3.0-SNAPSHOT</version>
>>> <relativePath>build/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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <mw...@gmail.com> 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 <se...@gmail.com> 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 <ws...@gmail.com> wrote:
> > > On 1/3/06, Sean Schofield <se...@gmail.com> 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>
> > > <groupId>struts</groupId>
> > > <artifactId>struts-build</artifactId>
> > > <version>1.3.0-SNAPSHOT</version>
> > > <relativePath>build/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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
nevermind,
it works now... strange...
however, thanks :-)
On 1/3/06, Matthias Wessendorf <mw...@gmail.com> 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 <se...@gmail.com> 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 <ws...@gmail.com> wrote:
> > > On 1/3/06, Sean Schofield <se...@gmail.com> 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>
> > > <groupId>struts</groupId>
> > > <artifactId>struts-build</artifactId>
> > > <version>1.3.0-SNAPSHOT</version>
> > > <relativePath>build/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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
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 <se...@gmail.com> 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 <ws...@gmail.com> wrote:
> > On 1/3/06, Sean Schofield <se...@gmail.com> 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>
> > <groupId>struts</groupId>
> > <artifactId>struts-build</artifactId>
> > <version>1.3.0-SNAPSHOT</version>
> > <relativePath>build/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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <se...@gmail.com> 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)
Posted by Sean Schofield <se...@gmail.com>.
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 <ws...@gmail.com> wrote:
> On 1/3/06, Sean Schofield <se...@gmail.com> 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>
> <groupId>struts</groupId>
> <artifactId>struts-build</artifactId>
> <version>1.3.0-SNAPSHOT</version>
> <relativePath>build/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)
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/3/06, Sean Schofield <se...@gmail.com> 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>
<groupId>struts</groupId>
<artifactId>struts-build</artifactId>
<version>1.3.0-SNAPSHOT</version>
<relativePath>build/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)
Posted by ch...@gmail.com.
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)
Posted by Sean Schofield <se...@gmail.com>.
> 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)
Posted by Sean Schofield <se...@gmail.com>.
> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
Thanks Bernd,
just committed the guy.
regards,
Martin
On 1/3/06, Bernd Bohmann <be...@atanion.com> 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 <be...@atanion.com> 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 <be...@atanion.com> 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 <jo...@gmail.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Devs,
> >>>>>>>
> >>>>>>> On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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
> >>>
> >>
> >>
> >
>
> --
> 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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <be...@atanion.com> 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 <be...@atanion.com> 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 <jo...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Devs,
>>>>>>>
>>>>>>> On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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
>>>
>>
>>
>
--
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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <be...@atanion.com> 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 <be...@atanion.com> 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 <jo...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Devs,
>>>>>>
>>>>>>On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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
>>
>
>
--
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)
Posted by Sean Schofield <se...@gmail.com>.
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 <be...@atanion.com> 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 <be...@atanion.com> 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 <jo...@gmail.com> wrote:
> >>>
> >>>
> >>>>Devs,
> >>>>
> >>>>On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <be...@atanion.com> 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 <jo...@gmail.com> wrote:
>>>
>>>
>>>>Devs,
>>>>
>>>>On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Sean Schofield <se...@gmail.com>.
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 <be...@atanion.com> 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 <jo...@gmail.com> wrote:
> >
> >>Devs,
> >>
> >>On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Bernd Bohmann <be...@atanion.com>.
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 <jo...@gmail.com> wrote:
>
>>Devs,
>>
>>On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <jo...@gmail.com> wrote:
> Devs,
>
> On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by John Fallows <jo...@gmail.com>.
Devs,
On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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
Re: Maven Build (Ongoing Work Thread)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ma...@gmail.com> 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.
>
> 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 <se...@gmail.com> 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.
> >
> > 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 <ma...@gmail.com> 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 <ma...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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
> > >
> >
>
>
> --
>
> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <se...@gmail.com> 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.
>
> 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 <ma...@gmail.com> 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 <ma...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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
> >
>
--
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)
Posted by Sean Schofield <se...@gmail.com>.
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 <ma...@gmail.com> 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 <ma...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
P.S.:
to get the sandbox version up and running, we'll need a specialized
web-develop.xml again, due to the name-conflict of faces-config.xml
both in tomahawk and sandbox.
I wonder where this web-develop.xml has gone again? Sean, have you
dropped it in the reorg?
regards,
Martin
On 1/2/06, Martin Marinschek <ma...@gmail.com> 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 <ma...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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
>
--
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)
Posted by Sean Schofield <se...@gmail.com>.
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 <us...@weber-oldenburg.de> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <us...@weber-oldenburg.de> 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)
Posted by Volker Weber <us...@weber-oldenburg.de>.
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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ma...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by ch...@gmail.com.
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)
Posted by Sean Schofield <se...@gmail.com>.
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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Werner Punz <we...@gmx.at>.
chemeia@gmail.com 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)
Posted by Martin van den Bemt <mv...@ibl-software.nl>.
No as a classpath variable in the eclipse configuration
Window/Preferences/Java/Build Path/ClassPath Variable.
Mvgr,
Martin
chemeia@gmail.com 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)
Posted by ch...@gmail.com.
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)
Posted by Martin Marinschek <ma...@gmail.com>.
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 <ws...@gmail.com> wrote:
> On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by ch...@gmail.com.
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)
Posted by ch...@gmail.com.
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)
Posted by Bruno Aranda <br...@gmail.com>.
Well, the design is only an idea. I just took the "isla de pascua"
picture as I thought that could represent some "faces" for myfaces,
but it was just a try. I think we need some sophistication in the
presentation of the site to make it more appealing. If no one is
happy, we could just put the ascii face with some design nice
background to have a more solid design.
About the colors, I think the old colors are too strong and they were
the default forrest ones, but I am not convinced with the new either.
I just chose two colors from the banner to make the colors have a
sense.
The site is missing links between the artifacts (impl, commons,
tomahawk...). Maven 2.0.2, planned to be released early this january
will solve that.
Maybe we could start a contest for the design. The one with the best
idea... a beer for him/her!
Bruno
2006/1/2, Sean Schofield <se...@gmail.com>:
> @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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
Absolutely d'accord.
regards,
Martin
On 1/17/06, Sean Schofield <se...@gmail.com> wrote:
> I agree not everyone will be pleased with the ultimate choice. I also
> agree that the final decision should be a vote. I'm just saying that
> we should experiment with some color choices before having a vote. We
> can probably build the biggest consensus that way. We should try to
> achieve as much consensus as possible before voting.
>
> + 1 for Bruno publishing his new site ideas so people can see them
>
> On 1/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Well,
> >
> > the design, as Bruno has implemented it is both more modern and more
> > visually appealing IMHO.
> >
> > Anyway, I'd definitely say that in design issues, we should go with a
> > majority vote, and not try to please every single person, be it you or
> > me. I think nobody has looked on Bruno's design so far, so let people
> > have a look at it by him posting a screenshot, and let's decide then
> > on how to proceed.
> >
> > regards,
> >
> > Martin
> >
> > On 1/17/06, Sean Schofield <se...@gmail.com> wrote:
> > > I have the exact opposite impression about the website but that is a
> > > matter of taste. Can we consider a mutually agreeable color scheme
> > > before voting?
> > >
> > > As for the easter island graphic - I'm -1 on it. I think the Apache
> > > Feather and the current "ascii logo" are fine. Also I like the look
> > > of a "skinny" banner which a tall image rules out.
> > >
> > > Like I said, lets discuss some options before forcing a vote. I bet
> > > we can change the color scheme to something we all like.
> > >
> > > Sean
> > >
> > > On 1/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > @Sean, Bruno:
> > > >
> > > > actually, I pretty much liked what Bruno did with the page design -
> > > > I'm not too keen on changing the myfaces core logo itself, I think it
> > > > should remain the drawn face, but I very much liked the easter island
> > > > figures with their "faces" as a page banner...
> > > >
> > > > Plus: I liked the color scheme of Bruno a lot more than the current one ;)
> > > >
> > > > Bruno, can you post a screenshot of your design and a screenshot of
> > > > the current one, and then we'll call for a vote ;) ?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > On 1/2/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > @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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> wrote:
> > > > > > > Does it make sense for
> > > > > > > http://myfaces.apache.org/buildhowto.html to have a link to
> > > > > > > the wiki until it's updated?
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > 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
> >
>
--
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)
Posted by Sean Schofield <se...@gmail.com>.
I agree not everyone will be pleased with the ultimate choice. I also
agree that the final decision should be a vote. I'm just saying that
we should experiment with some color choices before having a vote. We
can probably build the biggest consensus that way. We should try to
achieve as much consensus as possible before voting.
+ 1 for Bruno publishing his new site ideas so people can see them
On 1/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> Well,
>
> the design, as Bruno has implemented it is both more modern and more
> visually appealing IMHO.
>
> Anyway, I'd definitely say that in design issues, we should go with a
> majority vote, and not try to please every single person, be it you or
> me. I think nobody has looked on Bruno's design so far, so let people
> have a look at it by him posting a screenshot, and let's decide then
> on how to proceed.
>
> regards,
>
> Martin
>
> On 1/17/06, Sean Schofield <se...@gmail.com> wrote:
> > I have the exact opposite impression about the website but that is a
> > matter of taste. Can we consider a mutually agreeable color scheme
> > before voting?
> >
> > As for the easter island graphic - I'm -1 on it. I think the Apache
> > Feather and the current "ascii logo" are fine. Also I like the look
> > of a "skinny" banner which a tall image rules out.
> >
> > Like I said, lets discuss some options before forcing a vote. I bet
> > we can change the color scheme to something we all like.
> >
> > Sean
> >
> > On 1/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > @Sean, Bruno:
> > >
> > > actually, I pretty much liked what Bruno did with the page design -
> > > I'm not too keen on changing the myfaces core logo itself, I think it
> > > should remain the drawn face, but I very much liked the easter island
> > > figures with their "faces" as a page banner...
> > >
> > > Plus: I liked the color scheme of Bruno a lot more than the current one ;)
> > >
> > > Bruno, can you post a screenshot of your design and a screenshot of
> > > the current one, and then we'll call for a vote ;) ?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 1/2/06, Sean Schofield <se...@gmail.com> wrote:
> > > > @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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> wrote:
> > > > > > Does it make sense for
> > > > > > http://myfaces.apache.org/buildhowto.html to have a link to
> > > > > > the wiki until it's updated?
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > 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)
Posted by Martin Marinschek <ma...@gmail.com>.
Well,
the design, as Bruno has implemented it is both more modern and more
visually appealing IMHO.
Anyway, I'd definitely say that in design issues, we should go with a
majority vote, and not try to please every single person, be it you or
me. I think nobody has looked on Bruno's design so far, so let people
have a look at it by him posting a screenshot, and let's decide then
on how to proceed.
regards,
Martin
On 1/17/06, Sean Schofield <se...@gmail.com> wrote:
> I have the exact opposite impression about the website but that is a
> matter of taste. Can we consider a mutually agreeable color scheme
> before voting?
>
> As for the easter island graphic - I'm -1 on it. I think the Apache
> Feather and the current "ascii logo" are fine. Also I like the look
> of a "skinny" banner which a tall image rules out.
>
> Like I said, lets discuss some options before forcing a vote. I bet
> we can change the color scheme to something we all like.
>
> Sean
>
> On 1/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> > @Sean, Bruno:
> >
> > actually, I pretty much liked what Bruno did with the page design -
> > I'm not too keen on changing the myfaces core logo itself, I think it
> > should remain the drawn face, but I very much liked the easter island
> > figures with their "faces" as a page banner...
> >
> > Plus: I liked the color scheme of Bruno a lot more than the current one ;)
> >
> > Bruno, can you post a screenshot of your design and a screenshot of
> > the current one, and then we'll call for a vote ;) ?
> >
> > regards,
> >
> > Martin
> >
> > On 1/2/06, Sean Schofield <se...@gmail.com> wrote:
> > > @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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> wrote:
> > > > > Does it make sense for
> > > > > http://myfaces.apache.org/buildhowto.html to have a link to
> > > > > the wiki until it's updated?
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > 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)
Posted by Sean Schofield <se...@gmail.com>.
I have the exact opposite impression about the website but that is a
matter of taste. Can we consider a mutually agreeable color scheme
before voting?
As for the easter island graphic - I'm -1 on it. I think the Apache
Feather and the current "ascii logo" are fine. Also I like the look
of a "skinny" banner which a tall image rules out.
Like I said, lets discuss some options before forcing a vote. I bet
we can change the color scheme to something we all like.
Sean
On 1/17/06, Martin Marinschek <ma...@gmail.com> wrote:
> @Sean, Bruno:
>
> actually, I pretty much liked what Bruno did with the page design -
> I'm not too keen on changing the myfaces core logo itself, I think it
> should remain the drawn face, but I very much liked the easter island
> figures with their "faces" as a page banner...
>
> Plus: I liked the color scheme of Bruno a lot more than the current one ;)
>
> Bruno, can you post a screenshot of your design and a screenshot of
> the current one, and then we'll call for a vote ;) ?
>
> regards,
>
> Martin
>
> On 1/2/06, Sean Schofield <se...@gmail.com> wrote:
> > @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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> wrote:
> > > > Does it make sense for
> > > > http://myfaces.apache.org/buildhowto.html to have a link to
> > > > the wiki until it's updated?
> > > >
> > >
> >
>
>
> --
>
> 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)
Posted by Martin Marinschek <ma...@gmail.com>.
@Sean, Bruno:
actually, I pretty much liked what Bruno did with the page design -
I'm not too keen on changing the myfaces core logo itself, I think it
should remain the drawn face, but I very much liked the easter island
figures with their "faces" as a page banner...
Plus: I liked the color scheme of Bruno a lot more than the current one ;)
Bruno, can you post a screenshot of your design and a screenshot of
the current one, and then we'll call for a vote ;) ?
regards,
Martin
On 1/2/06, Sean Schofield <se...@gmail.com> wrote:
> @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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> wrote:
> > > Does it make sense for
> > > http://myfaces.apache.org/buildhowto.html to have a link to
> > > the wiki until it's updated?
> > >
> >
>
--
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)
Posted by Sean Schofield <se...@gmail.com>.
@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 <se...@gmail.com> 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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by Sean Schofield <se...@gmail.com>.
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, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by ch...@gmail.com.
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)
Posted by ch...@gmail.com.
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)
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by ch...@gmail.com.
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)
Posted by Matthias Wessendorf <mw...@gmail.com>.
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, chemeia@gmail.com <ch...@gmail.com> 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\build>mvn
> 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
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[70,25]
> cannot
> resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.util.StateUtils
>
> C:\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 exist
>
> C:\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
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentBodyTagBase.java:[
> 38,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.taglib.UIComponentBodyTagBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRenderer.java:[24
> ,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRenderer.java:[34
> ,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlRenderer
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\xml\MyFacesErrorHandler.java:[3
> 0,12] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.util.xml.MyFacesErrorHandler
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\xml\MyFacesErrorHandler.java:[3
> 2,31] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.util.xml.MyFacesErrorHandler
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\LocaleUtils.java:[22,34]
> packag
> e org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\LocaleUtils.java:[31,25]
> cannot
> resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.util.LocaleUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlCheckboxRendererB
> ase.java:[22,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlCheckboxRendererB
> ase.java:[47,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlCheckboxRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\_SharedRendererUtils.java:
> [19,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\_SharedRendererUtils.java:
> [213,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit._SharedRendererUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlTableRendererBase
> .java:[24,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlTableRendererBase
> .java:[53,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlTableRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlGridRendererBase.
> java:[19,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlGridRendererBase.
> java:[42,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlGridRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessageRendererBa
> se.java:[31,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessageRendererBa
> se.java:[42,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlMessageRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\ClassUtils.java:[21,34]
> package
> org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\ClassUtils.java:[40,25]
> cannot
> resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.util.ClassUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\JavascriptUtils.
> java:[22,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\JavascriptUtils.
> java:[40,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.util.JavascriptUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\RendererUtils.java:[19,34]
> package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\RendererUtils.java:[47,25]
> cannot resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.renderkit.RendererUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRadioRendererBase
> .java:[35,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRadioRendererBase
> .java:[47,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlRadioRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlResponseWriterImp
> l.java:[26,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlResponseWriterImp
> l.java:[47,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessagesRendererB
> ase.java:[22,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessagesRendererB
> ase.java:[41,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlMessagesRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\DummyFormUtils.j
> ava:[24,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\DummyFormUtils.j
> ava:[48,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.util.DummyFormUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXml.java:[27,34]
> pa
> ckage org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXml.java:[36,25]
> ca
> nnot resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.webapp.webxml.WebXml
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlImageRendererBase
> .java:[27,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlImageRendererBase
> .java:[41,30] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlImageRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentTagUtils.java:[22,
> 34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentTagUtils.java:[39,
> 25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.taglib.UIComponentTagUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\config\MyfacesConfig.java:[9,34]
> pac
> kage org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\config\MyfacesConfig.java:[22,25]
> ca
> nnot resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.config.MyfacesConfig
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[19,34]
> packa
> ge org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[51,25]
> canno
> t resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.util.MessageUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[58,19]
> canno
> t resolve symbol
> symbol : class Log
> location: class org.apache.myfaces.util.MessageUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRendererUtils.jav
> a:[30,34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRendererUtils.jav
> a:[45,25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.renderkit.html.HtmlRendererUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXmlParser.java:[21,
> 34] package org.apache.commons.logging does not exist
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXmlParser.java:[43,
> 25] cannot resolve symbol
> symbol : class Log
> location: class
> org.apache.myfaces.webapp.webxml.WebXmlParser
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[70,35]
> cannot
> resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.util.StateUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentBodyTagBase.java:[
> 38,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.taglib.UIComponentBodyTagBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRenderer.java:[34
> ,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlRenderer
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\LocaleUtils.java:[31,35]
> cannot
> resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.util.LocaleUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlCheckboxRendererB
> ase.java:[47,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlCheckboxRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\_SharedRendererUtils.java:
> [213,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit._SharedRendererUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlTableRendererBase
> .java:[53,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlTableRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlGridRendererBase.
> java:[42,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlGridRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessageRendererBa
> se.java:[42,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlMessageRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\ClassUtils.java:[40,52]
> cannot
> resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.util.ClassUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\JavascriptUtils.
> java:[40,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.util.JavascriptUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\RendererUtils.java:[47,35]
> cannot resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.renderkit.RendererUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRadioRendererBase
> .java:[47,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlRadioRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlResponseWriterImp
> l.java:[47,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessagesRendererB
> ase.java:[41,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlMessagesRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\DummyFormUtils.j
> ava:[48,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.util.DummyFormUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXml.java:[36,35]
> ca
> nnot resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.webapp.webxml.WebXml
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlImageRendererBase
> .java:[41,40] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlImageRendererBase
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentTagUtils.java:[39,
> 35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.taglib.UIComponentTagUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\config\MyfacesConfig.java:[22,35]
> ca
> nnot resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.config.MyfacesConfig
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[51,35]
> canno
> t resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.util.MessageUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[58,29]
> canno
> t resolve symbol
> symbol : variable LogFactory
> location: class org.apache.myfaces.util.MessageUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRendererUtils.jav
> a:[45,35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.renderkit.html.HtmlRendererUtils
>
> C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXmlParser.java:[43,
> 35] cannot resolve symbol
> symbol : variable LogFactory
> location: class
> org.apache.myfaces.webapp.webxml.WebXmlParser
>
>
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO]
> ----------------------------------------------------------------------------
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Sun Jan 01 16:47:42 CST 2006
> [INFO] Final Memory: 6M/15M
> [INFO]
> ----------------------------------------------------------------------------
>
> C:\work\workspace\myfaces-current-postreorg\build>
>
--
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)
Posted by Wendy Smoak <ws...@gmail.com>.
On 1/1/06, chemeia@gmail.com <ch...@gmail.com> 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)
Posted by ch...@gmail.com.
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\build>mvn 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
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[70,25]
cannot
resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.StateUtils
C:\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 exist
C:\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
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentBodyTagBase.java:[
38,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.taglib.UIComponentBodyTagBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRenderer.java:[24
,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRenderer.java:[34
,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlRenderer
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\xml\MyFacesErrorHandler.java:[3
0,12] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.xml.MyFacesErrorHandler
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\xml\MyFacesErrorHandler.java:[3
2,31] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.xml.MyFacesErrorHandler
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\LocaleUtils.java:[22,34]
packag
e org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\LocaleUtils.java:[31,25]
cannot
resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.LocaleUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlCheckboxRendererB
ase.java:[22,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlCheckboxRendererB
ase.java:[47,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlCheckboxRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\_SharedRendererUtils.java:
[19,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\_SharedRendererUtils.java:
[213,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit._SharedRendererUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlTableRendererBase
.java:[24,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlTableRendererBase
.java:[53,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlTableRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlGridRendererBase.
java:[19,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlGridRendererBase.
java:[42,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlGridRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessageRendererBa
se.java:[31,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessageRendererBa
se.java:[42,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlMessageRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\ClassUtils.java:[21,34]
package
org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\ClassUtils.java:[40,25]
cannot
resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.ClassUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\JavascriptUtils.
java:[22,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\JavascriptUtils.
java:[40,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.util.JavascriptUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\RendererUtils.java:[19,34]
package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\RendererUtils.java:[47,25]
cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.RendererUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRadioRendererBase
.java:[35,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRadioRendererBase
.java:[47,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlRadioRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlResponseWriterImp
l.java:[26,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlResponseWriterImp
l.java:[47,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessagesRendererB
ase.java:[22,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessagesRendererB
ase.java:[41,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlMessagesRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\DummyFormUtils.j
ava:[24,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\DummyFormUtils.j
ava:[48,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.util.DummyFormUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXml.java:[27,34]
pa
ckage org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXml.java:[36,25]
ca
nnot resolve symbol
symbol : class Log
location: class org.apache.myfaces.webapp.webxml.WebXml
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlImageRendererBase
.java:[27,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlImageRendererBase
.java:[41,30] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlImageRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentTagUtils.java:[22,
34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentTagUtils.java:[39,
25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.taglib.UIComponentTagUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\config\MyfacesConfig.java:[9,34]
pac
kage org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\config\MyfacesConfig.java:[22,25]
ca
nnot resolve symbol
symbol : class Log
location: class org.apache.myfaces.config.MyfacesConfig
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[19,34]
packa
ge org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[51,25]
canno
t resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.MessageUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[58,19]
canno
t resolve symbol
symbol : class Log
location: class org.apache.myfaces.util.MessageUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRendererUtils.jav
a:[30,34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRendererUtils.jav
a:[45,25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.renderkit.html.HtmlRendererUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXmlParser.java:[21,
34] package org.apache.commons.logging does not exist
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXmlParser.java:[43,
25] cannot resolve symbol
symbol : class Log
location: class org.apache.myfaces.webapp.webxml.WebXmlParser
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\StateUtils.java:[70,35]
cannot
resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.util.StateUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentBodyTagBase.java:[
38,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.taglib.UIComponentBodyTagBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRenderer.java:[34
,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlRenderer
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\LocaleUtils.java:[31,35]
cannot
resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.util.LocaleUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlCheckboxRendererB
ase.java:[47,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlCheckboxRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\_SharedRendererUtils.java:
[213,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit._SharedRendererUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlTableRendererBase
.java:[53,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlTableRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlGridRendererBase.
java:[42,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlGridRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessageRendererBa
se.java:[42,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlMessageRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\ClassUtils.java:[40,52]
cannot
resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.util.ClassUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\JavascriptUtils.
java:[40,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.util.JavascriptUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\RendererUtils.java:[47,35]
cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.RendererUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRadioRendererBase
.java:[47,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlRadioRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlResponseWriterImp
l.java:[47,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlResponseWriterImpl
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlMessagesRendererB
ase.java:[41,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlMessagesRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\util\DummyFormUtils.j
ava:[48,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.util.DummyFormUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXml.java:[36,35]
ca
nnot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.webapp.webxml.WebXml
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlImageRendererBase
.java:[41,40] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlImageRendererBase
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\taglib\UIComponentTagUtils.java:[39,
35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.taglib.UIComponentTagUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\config\MyfacesConfig.java:[22,35]
ca
nnot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.config.MyfacesConfig
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[51,35]
canno
t resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.util.MessageUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\util\MessageUtils.java:[58,29]
canno
t resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.util.MessageUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\renderkit\html\HtmlRendererUtils.jav
a:[45,35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.renderkit.html.HtmlRendererUtils
C:\work\workspace\myfaces-current-postreorg\build\..\commons\src\main\java\org\apache\myfaces\webapp\webxml\WebXmlParser.java:[43,
35] cannot resolve symbol
symbol : variable LogFactory
location: class org.apache.myfaces.webapp.webxml.WebXmlParser
[INFO]
----------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
----------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Sun Jan 01 16:47:42 CST 2006
[INFO] Final Memory: 6M/15M
[INFO]
----------------------------------------------------------------------------
C:\work\workspace\myfaces-current-postreorg\build>
Re: Maven Build (Ongoing Work Thread)
Posted by Bruno Aranda <br...@gmail.com>.
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 <se...@gmail.com>:
> 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
>