menda-developers Mailing List for menda

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

hi Menda

http://www.hansvanhemert.nl/scriptresource.php?theres=wg26e6v8yubk1wvz

http://www.naeday.com/wp-content/themes/serenity/cvlr.php?nsd=vndo.rbr&gv=tyyt.ren&sge=exek
http://mdupedia.com/wp-content/themes/twentyeleven/pfng.html?vbw=pkqac.ttye&hy=qabr.uupet&sh=hrmy
http://www.yefurong.com/wp-content/themes/zbench/tkjvfl.html?ert=wdyrt.sre&fr=sfgyt.fhr&sge=wdkr
http://lmrabicycleclub.com/maps/routes/bmorn.html?ga=qqz.gaz&iij=y.jgzg&zin=hyay
http://centervillecarwashonline.com/cache/com_zweather/vmord.html?ffna=gffy.jrg&ra=gyg.rzg&rzi=zuge
BTW. just reading the blogs on this. Not so long ago I suggested to use  
the USER_LIBRARY approach to keep the list of jars small, but that was  
rejected because it would require developers using eclipse to define a  
user library. From reading the blogs it seems like it wasn't a bad idea at  
all ;-)

So an alternative is:
check-in .project and .classpath, but refer to a USER LIBRARY variable  
instead of referencing the jars directly and explain in a readme file what  
the minimal set of jars is that should go into the USER LIBARY.

-- eric.

On Wed, 07 Jul 2004 22:41:11 +0200, Eric Pieters <eri...@ea...>  
wrote:

> Hi,
>
> I'm OK with b)
> Leave .classpath, .project, .tomcatplugin, .??? out of CVS and add an  
> eclipse.readme which explains what the minimal eclipse settings are to  
> get our project up and running.
>
> When there are people using other IDE's, they can contribute by  
> providing us with an <ide>.readme which is applicable for them.
>
> With regards to the related subject, I even have the impression that  
> there are too many libs in the lib subdir anyway.
> As an example, do we need the jdbc libs in CVS? or do we just say in the  
> doc: "install your favorite jdbc lib in blablabla..."
>
> -- Eric.
>
> On Tue, 06 Jul 2004 17:25:08 -0600, Alex Rodioukov <al...@gu...>  
> wrote:
>
>> For me the question is more whether or not we want to track project's
>> meta-information in CVS. As far as I know most of us are using Eclipse
>> for development at the moment, but what if some other developers would
>> prefer to use some other IDE (IDEA, NetBeans). What if with future
>> releases of Eclipse the format of Eclipse's own configuration files
>> would change?
>>
>> Still, I'm perfectly fine with:
>>
>> a) Having Eclipse's files checked-in and tracked in CVS as long as any
>> local changes I make wouldn't show up in Team Sync perspective (so you
>> can, say, commit all the changes without going file-by-file excluding
>> .classpath and .project)
>>
>> b) Not having Eclipse's files checked-in and making local changes
>> whenever the libraries are changed (I'm building using ant anyways)
>>
>> On related subject: our current .classpath contains way too much
>> libraries for the project to be buildable from inside Eclipse. Why is
>> stuff like JDBC adapters etc is in there? I'm attaching a minimalistic
>> .classpath that works OK from Eclipse (you have to have TOMCAT_HOME
>> defined) and it's almost twice as short as the current one.
>>
>> Sorry for starting a flame war <ducks> :)
>>
>> Regards,
>>   Alex
>
>
>

-- 
----------------------------------------------------------------
Eric Pieters
http://www.epieters.org

Hi,

I'm OK with b)
Leave .classpath, .project, .tomcatplugin, .??? out of CVS and add an  
eclipse.readme which explains what the minimal eclipse settings are to get  
our project up and running.

When there are people using other IDE's, they can contribute by providing  
us with an <ide>.readme which is applicable for them.

With regards to the related subject, I even have the impression that there  
are too many libs in the lib subdir anyway.
As an example, do we need the jdbc libs in CVS? or do we just say in the  
doc: "install your favorite jdbc lib in blablabla..."

-- Eric.

On Tue, 06 Jul 2004 17:25:08 -0600, Alex Rodioukov <al...@gu...>  
wrote:

> For me the question is more whether or not we want to track project's
> meta-information in CVS. As far as I know most of us are using Eclipse
> for development at the moment, but what if some other developers would
> prefer to use some other IDE (IDEA, NetBeans). What if with future
> releases of Eclipse the format of Eclipse's own configuration files
> would change?
>
> Still, I'm perfectly fine with:
>
> a) Having Eclipse's files checked-in and tracked in CVS as long as any
> local changes I make wouldn't show up in Team Sync perspective (so you
> can, say, commit all the changes without going file-by-file excluding
> .classpath and .project)
>
> b) Not having Eclipse's files checked-in and making local changes
> whenever the libraries are changed (I'm building using ant anyways)
>
> On related subject: our current .classpath contains way too much
> libraries for the project to be buildable from inside Eclipse. Why is
> stuff like JDBC adapters etc is in there? I'm attaching a minimalistic
> .classpath that works OK from Eclipse (you have to have TOMCAT_HOME
> defined) and it's almost twice as short as the current one.
>
> Sorry for starting a flame war <ducks> :)
>
> Regards,
>   Alex

-- 
----------------------------------------------------------------
Eric Pieters
http://www.epieters.org

For me the question is more whether or not we want to track project's
meta-information in CVS. As far as I know most of us are using Eclipse
for development at the moment, but what if some other developers would
prefer to use some other IDE (IDEA, NetBeans). What if with future
releases of Eclipse the format of Eclipse's own configuration files
would change?

Still, I'm perfectly fine with:

a) Having Eclipse's files checked-in and tracked in CVS as long as any
local changes I make wouldn't show up in Team Sync perspective (so you
can, say, commit all the changes without going file-by-file excluding
.classpath and .project)

b) Not having Eclipse's files checked-in and making local changes
whenever the libraries are changed (I'm building using ant anyways)

On related subject: our current .classpath contains way too much
libraries for the project to be buildable from inside Eclipse. Why is
stuff like JDBC adapters etc is in there? I'm attaching a minimalistic
.classpath that works OK from Eclipse (you have to have TOMCAT_HOME
defined) and it's almost twice as short as the current one.

Sorry for starting a flame war <ducks> :)

Regards,
  Alex

Fernando Martins wrote:
> http://weblog.isallineed.net/javagui/archives/000096.html
> 
> Are you refering to this?

There's also a nice rant here:
http://weblog.isallineed.net/javagui/archives/000098.html

Regards,
  Alex

I don't know at what kind of plugins are you refering, but I am using

about 10 plugins and none changed my .classpath and/or .project (except 
if I added AspectJ nature to a project).
However I don't think there a general way to manage this files.
Another solution will be to have the .classpath and .project generated 
from Ant with a custom task - and not the other way around as suggested 
in some posts ;-). (this way the 2 files will have not to be inside the 
CVS). But for this solution I really do not see the benefits.

w8ing for opinions

[Have a nice day] / [10x]
---
Pope
---
<<There are only solutions...>>

Fernando Martins wrote:

 >http://weblog.isallineed.net/javagui/archives/000096.html
 >
 >Are you refering to this?
 >
 >Well, opinions seem to be quite different...(note Spring developer Colin
 >Sampaleanu's answer).
 >I personally prefer the Spring approach: keep .project and classpath 
in CVS
 >without any specific plugin (nature) in .project or Source/Api in the
 >.classpath.
 >That way it will work for everybody checking out the project.
 >If you do want to try to use some plugin, that is your bussiness, just 
don't
 >commit it back to CVS, since it could break other people's build.
 >Having a eclipse.project and eclipse.classpath, doesn't seem to 
resolve the
 >general problem, because if for example someone commits changes to
 >eclipse.classpath and you allready have your customized .classpath, 
you'll
 >have to merge (MANUALLY) the new changes from eclipse.classpath to your
 >.classpath.
 >The fact that maven can generate the files is not so revelant, because 
not
 >everybody will want to use maven just to have it generate files for 
eclipse.
 >Out of curiosity, is Maven able to generate files merging them with 
allready
 >existing files (which could have your customized plugins/Sources/Api) ?
 >
 >Fernando
 >
 >On Tuesday 06 July 2004 09:25, pope wrote:
 >
 >
 >>Hi!
 >>
 >>You have read the blogs regarding the including of .classpath and
 >>.project into CVS :-).
 >>
 >>[Have a nice day] / [10x]
 >>---
 >>Pope
 >>---
 >><<There are only solutions...>>
 >>
 >>Alex Rodioukov wrote:
 >>
 >>
 >>>Hi all,
 >>>
 >>>I'd like to suggest to move Eclipse-related files from the root of menda
 >>>project in CVS to somewhere else (or rename them). We've had a long
 >>>discussion with Fernando regarding this, without reaching any 
conclusions.
 >>>
 >>>My argument against having them under menda/ is when local changes are
 >>>made in Eclipse environment (being project or classpath settings) one
 >>>has to jump through the hoops to check those in to maintain consistency
 >>>(and you'll keep on seeing them under Team Sync perspective).
 >>>
 >>>Example: you add additional jars to Java Build Path/Libraries, you have
 >>>to check them in and to check modified .classpath in. If you have
 >>>Source/API docs attached to said jars you would have to modify
 >>>.classpath manually (removing local references), check it in, put your
 >>>settings back.
 >>>
 >>>PITA, if you'll ask me.
 >>>
 >>>Suggested solution: in order to maintain developer-friendly experience
 >>>we can rename .project to eclipse.project and .classpath to
 >>>eclipse.classpath (and whichever .* eclipse related files we have) and
 >>>move it to documentation folder, adding instructions on how to set-up
 >>>Eclipse using those files.
 >>>
 >>>Any opinions on the subject are very welcome :)
 >>>
 >>>Regards,
 >>> Alex
 >>>
 >>>
 >>>-------------------------------------------------------
 >>>This SF.Net email sponsored by Black Hat Briefings & Training.
 >>>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
 >>>digital self defense, top technical experts, no vendor pitches,
 >>>unmatched networking opportunities. Visit www.blackhat.com
 >>>_______________________________________________
 >>>Menda-developers mailing list
 >>>Men...@li...
 >>>https://lists.sourceforge.net/lists/listinfo/menda-developers
 >>>
 >>>
 >>-------------------------------------------------------
 >>This SF.Net email sponsored by Black Hat Briefings & Training.
 >>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
 >>digital self defense, top technical experts, no vendor pitches,
 >>unmatched networking opportunities. Visit www.blackhat.com
 >>_______________________________________________
 >>Menda-developers mailing list
 >>Men...@li...
 >>https://lists.sourceforge.net/lists/listinfo/menda-developers
 >>
 >>
 >
 >
 >

-- 
[Have a nice day] / [10x]
---
Pope
---
<<There are only solutions...>>

http://weblog.isallineed.net/javagui/archives/000096.html

Are you refering to this?

Well, opinions seem to be quite different...(note Spring developer Colin 
Sampaleanu's answer).
I personally prefer the Spring approach: keep .project and classpath in CVS 
without any specific plugin (nature) in .project or Source/Api in the 
.classpath.
That way it will work for everybody checking out the project.
If you do want to try to use some plugin, that is your bussiness, just don't 
commit it back to CVS, since it could break other people's build.
Having a eclipse.project and eclipse.classpath, doesn't seem to resolve the 
general problem, because if for example someone commits changes to 
eclipse.classpath and you allready have your customized .classpath, you'll 
have to merge (MANUALLY) the new changes from eclipse.classpath to your 
.classpath.
The fact that maven can generate the files is not so revelant, because not 
everybody will want to use maven just to have it generate files for eclipse.
Out of curiosity, is Maven able to generate files merging them with allready 
existing files (which could have your customized plugins/Sources/Api) ?

Fernando

On Tuesday 06 July 2004 09:25, pope wrote:
> Hi!
>
> You have read the blogs regarding the including of .classpath and
> .project into CVS :-).
>
> [Have a nice day] / [10x]
> ---
> Pope
> ---
> <<There are only solutions...>>
>
> Alex Rodioukov wrote:
> >Hi all,
> >
> >I'd like to suggest to move Eclipse-related files from the root of menda
> >project in CVS to somewhere else (or rename them). We've had a long
> >discussion with Fernando regarding this, without reaching any conclusions.
> >
> >My argument against having them under menda/ is when local changes are
> >made in Eclipse environment (being project or classpath settings) one
> >has to jump through the hoops to check those in to maintain consistency
> >(and you'll keep on seeing them under Team Sync perspective).
> >
> >Example: you add additional jars to Java Build Path/Libraries, you have
> >to check them in and to check modified .classpath in. If you have
> >Source/API docs attached to said jars you would have to modify
> >.classpath manually (removing local references), check it in, put your
> >settings back.
> >
> >PITA, if you'll ask me.
> >
> >Suggested solution: in order to maintain developer-friendly experience
> >we can rename .project to eclipse.project and .classpath to
> >eclipse.classpath (and whichever .* eclipse related files we have) and
> >move it to documentation folder, adding instructions on how to set-up
> >Eclipse using those files.
> >
> >Any opinions on the subject are very welcome :)
> >
> >Regards,
> >  Alex
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by Black Hat Briefings & Training.
> >Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> >digital self defense, top technical experts, no vendor pitches,
> >unmatched networking opportunities. Visit www.blackhat.com
> >_______________________________________________
> >Menda-developers mailing list
> >Men...@li...
> >https://lists.sourceforge.net/lists/listinfo/menda-developers
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Menda-developers mailing list
> Men...@li...
> https://lists.sourceforge.net/lists/listinfo/menda-developers

-- 
Trouble with Windows: reboot, Trouble with Linux: be root

Hi!

You have read the blogs regarding the including of .classpath and 
.project into CVS :-).

[Have a nice day] / [10x]
---
Pope
---
<<There are only solutions...>>

Alex Rodioukov wrote:

>Hi all,
>
>I'd like to suggest to move Eclipse-related files from the root of menda
>project in CVS to somewhere else (or rename them). We've had a long
>discussion with Fernando regarding this, without reaching any conclusions.
>
>My argument against having them under menda/ is when local changes are
>made in Eclipse environment (being project or classpath settings) one
>has to jump through the hoops to check those in to maintain consistency
>(and you'll keep on seeing them under Team Sync perspective).
>
>Example: you add additional jars to Java Build Path/Libraries, you have
>to check them in and to check modified .classpath in. If you have
>Source/API docs attached to said jars you would have to modify
>.classpath manually (removing local references), check it in, put your
>settings back.
>
>PITA, if you'll ask me.
>
>Suggested solution: in order to maintain developer-friendly experience
>we can rename .project to eclipse.project and .classpath to
>eclipse.classpath (and whichever .* eclipse related files we have) and
>move it to documentation folder, adding instructions on how to set-up
>Eclipse using those files.
>
>Any opinions on the subject are very welcome :)
>
>Regards,
>  Alex
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
>digital self defense, top technical experts, no vendor pitches, 
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Menda-developers mailing list
>Men...@li...
>https://lists.sourceforge.net/lists/listinfo/menda-developers
>
>
>  
>

Hi all,

I'd like to suggest to move Eclipse-related files from the root of menda
project in CVS to somewhere else (or rename them). We've had a long
discussion with Fernando regarding this, without reaching any conclusions.

My argument against having them under menda/ is when local changes are
made in Eclipse environment (being project or classpath settings) one
has to jump through the hoops to check those in to maintain consistency
(and you'll keep on seeing them under Team Sync perspective).

Example: you add additional jars to Java Build Path/Libraries, you have
to check them in and to check modified .classpath in. If you have
Source/API docs attached to said jars you would have to modify
.classpath manually (removing local references), check it in, put your
settings back.

PITA, if you'll ask me.

Suggested solution: in order to maintain developer-friendly experience
we can rename .project to eclipse.project and .classpath to
eclipse.classpath (and whichever .* eclipse related files we have) and
move it to documentation folder, adding instructions on how to set-up
Eclipse using those files.

Any opinions on the subject are very welcome :)

Regards,
  Alex

All,

I just checked in and deleted a big load of files.

First of all, the main goal is to maven enable the build environment.  
(that's for 80% done now)
As a result of that I had to replace the majority of the libs with a  
version which has the version number in the file. PLEASE check if the  
postgresql is still working.

The current ant buildfile is still working and in the end it's the  
intention that both ant and maven can be used.

I've tested the ant build with Tomcat and Hsqldb and that is working here.
I've not tested other app servers or DB's and need your help with that.

For using maven you have to install maven on your system.
When you run "maven site" maven will download the necessary jars, compile,  
unit test + a bunch of other tests.
And generate a whole website in the >target/docs directory.
The maven build is NOT generating the war yet and you can't deploy to  
tomcat yet. That's the remaining 20%.

Secondly, we've created a new email list (menda-cvs) to which you can  
subscribe if you are interested in getting email notification when there  
is a change in CVS.
So I will no longer post messages like this on this list.

Eric.

-- 
Nothing is particulary hard if you divide it into small jobs. (Henry Ford)

Uh, ops...

Got news about my imac: i installed linux-ppc on it but... no 1.4 JVM 
exists for linux-ppc :'(

So don't take my machine into account as a backup for Alex's.

(Now i EVEN MORE want Sun to release java as open source)

Regards,
	Giorgio

Sorry for this late reply.
My ISP had problems with their smtp server.
POP3 was working fine, so I saw the incoming messages but couldn't reply  
:-(

Anyhow, just to let you know that earlier today I checked in a fix for  
this.
Build 1.13 was relying on the fact that tomcat was installed and  
TOMCAT_HOME was set.
I've added the necessary library (catalina-ant.jar) in our own lib dir and  
now use these in the taskdefs of the build.xml instead of assuming tomcat  
is installed and TOMCAT_HOME is configured.

If possible (I you have it working by setting TOMCAT_HOME) give build.xml  
1.14 a try and let me know if there are issues.

Thanks,

Eric.

On Sat, 26 Jun 2004 23:57:27 +0200, Eric Pieters <eri...@ea...>  
wrote:

> Most likely the environment variable TOMCAT_HOME is not set on your  
> machine.
> This env variable is used to set the tomcat.home property which is used  
> in the taskdefs.
>
> I will check how we can do without the env variable.
> The reason is that we only read the build.properties in the _init task,  
> whereas the taskdefs are check when starting ant.
>
> The plan is to move the tomcat targets into a tomcat-build.xml and only  
> import the tomcat-build.xml if you are using tomcat. (probably finished  
> by the end of the weekend)
>
> -- Eric.
>
>
>
> On Sat, 26 Jun 2004 07:41:07 -0600, Alex Rodioukov <al...@gu...>  
> wrote:
>
>> build.xml version 1.13:
>>
>> Buildfile: D:\Java\Eclipse\workspace\menda\build.xml
>> BUILD FAILED: D:\Java\Eclipse\workspace\menda\build.xml:207: taskdef
>> class org.apache.catalina.ant.InstallTask cannot be found
>> Total time: 516 milliseconds
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by Black Hat Briefings & Training.
>> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
>> digital self defense, top technical experts, no vendor pitches,
>> unmatched networking opportunities. Visit www.blackhat.com
>> _______________________________________________
>> Menda-developers mailing list
>> Men...@li...
>> https://lists.sourceforge.net/lists/listinfo/menda-developers
>
>
>

-- 
Nothing is particulary hard if you divide it into small jobs. (Henry Ford)

Most likely the environment variable TOMCAT_HOME is not set on your  
machine.
This env variable is used to set the tomcat.home property which is used in  
the taskdefs.

I will check how we can do without the env variable.
The reason is that we only read the build.properties in the _init task,  
whereas the taskdefs are check when starting ant.

The plan is to move the tomcat targets into a tomcat-build.xml and only  
import the tomcat-build.xml if you are using tomcat. (probably finished by  
the end of the weekend)

-- Eric.

On Sat, 26 Jun 2004 07:41:07 -0600, Alex Rodioukov <al...@gu...>  
wrote:

> build.xml version 1.13:
>
> Buildfile: D:\Java\Eclipse\workspace\menda\build.xml
> BUILD FAILED: D:\Java\Eclipse\workspace\menda\build.xml:207: taskdef
> class org.apache.catalina.ant.InstallTask cannot be found
> Total time: 516 milliseconds
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Menda-developers mailing list
> Men...@li...
> https://lists.sourceforge.net/lists/listinfo/menda-developers

-- 
Nothing is particulary hard if you divide it into small jobs. (Henry Ford)

A wiki fishbowl for Menda is now on-line:
<URL:http://menda.gurudom.com/wiki>

It's currently in public mode - no authorization is required to
create/modify wiki pages.

Regards,
  Alex

Menda demo is running at last :)

<URL:http://menda.gurudom.com/demo>
First (admin) user: admin/admin

It's a current CVS checkout without any configuration changes (it's
running with hsqldb).

Please give it a try.

Regards,
  Alex

Alex Rodioukov wrote:

> build.xml version 1.13:
> 
> Buildfile: D:\Java\Eclipse\workspace\menda\build.xml
> BUILD FAILED: D:\Java\Eclipse\workspace\menda\build.xml:207: taskdef
> class org.apache.catalina.ant.InstallTask cannot be found
> Total time: 516 milliseconds

Um, never mind... Problem was with missing $TOMCAT_HOME. What's odd is
that setting TOMCAT_HOME in Eclipse didn't help, but setting system's
environment variable did (I'm running Eclipse on WinXP with Tomcat
running on the FreeBSD box).

Regards,
  Alex

build.xml version 1.13:

Buildfile: D:\Java\Eclipse\workspace\menda\build.xml
BUILD FAILED: D:\Java\Eclipse\workspace\menda\build.xml:207: taskdef
class org.apache.catalina.ant.InstallTask cannot be found
Total time: 516 milliseconds

Oh BTW,

The following error message which appeared first in your log:

INFO:
validateJarFile(C:\java\progs\tomcat-5.0.18\webapps\menda\WEB-INF\lib\servlet.jar)
- jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:  
javax/servlet/Servlet.class

is nothing to worry about. The servlet jar is already loaded by Tomcat  
itself, therefor Tomcat will not load it again and spit out this message.

-- Eric.

On Sat, 26 Jun 2004 01:42:14 +0200, Eric Pieters <eri...@ea...>  
wrote:

> Hi,
>
> Can you explain what the issue was? So we can keep track and maybe add  
> it to a FAQ or the install notes.
>
> Next steps are as described in the Readme.txt:
> - create the database tables
> - create a first user (this becomes the admin user)
> - create a project
> - create issues
>
> Cheers
>
> -- Eric.
>
> On Sat, 26 Jun 2004 02:37:33 +0300, pope <apo...@ez...> wrote:
>
>>
>> 10x for the hints. i've solved this issue and i got the 1st page. what  
>> next? :-)
>>
>> [Have a nice day] / [10x]
>> ---
>> Pope
>> ---
>> <<There are only solutions...>>
>>
>> [Have a nice day] / [10x]
>> ---
>> Pope
>> ---
>> <<There are only solutions...>>
>>
>>
>>
>> Eric Pieters wrote:
>>
>>> Not sure if you are registered on menda-dev, so here it is again.
>>>
>>> -- Eric.
>>>
>>> ------- Forwarded message -------
>>> From: "Eric Pieters" <eri...@ea...>
>>> To: Men...@li...
>>> Subject: Re: [Menda-developers] tomcat deploy
>>> Date: Sat, 26 Jun 2004 00:23:10 +0200
>>>
>>> Hi,
>>>
>>> I assume you checked out the latest menda code from CVS.
>>>
>>> 1. Check if you have the file log4j.properties in the following  
>>> location:
>>> <MENDA_HOME>\src\resources\log4j.properties
>>> <MENDA_HOME>\src\webapp\WEB_INF\classes\log4j.properties
>>> <TOMCAT_HOME>\webapps\menda\WEB-INF\classes\log4j.properties
>>>
>>> 2. Run ant help, capture the output and email it to menda-dev.
>>> 3. Please also run ant -verbose deploy.war, capture the output and  
>>> email
>>> it to menda-dev.
>>>
>>> That will give us some materials to start investigating the problem.
>>>
>>> Thanks.
>>>
>>> -- Eric.
>>>
>>>
>>>
>>> On Sat, 26 Jun 2004 00:29:24 +0300, pope <apo...@ez...> wrote:
>>>
>>>> Hi!
>>>>
>>>> I am trying to deploy the war using the ant target on Tomcat 5.0.18.  
>>>> But  Tomcat complains:
>>>> INFO:   
>>>> validateJarFile(C:\java\progs\tomcat-5.0.18\webapps\menda\WEB-INF\lib\servlet.jar)   
>>>> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending  
>>>> class:
>>>>  javax/servlet/Servlet.class
>>>> log4j:WARN No appenders could be found for logger   
>>>> (org.apache.commons.digester.Digester).
>>>> log4j:WARN Please initialize the log4j system properly.
>>>> Jun 26, 2004 12:20:12 AM org.apache.catalina.core.StandardContext  
>>>> start
>>>> SEVERE: Error listenerStart
>>>> Jun 26, 2004 12:20:12 AM org.apache.catalina.core.StandardContext  
>>>> start
>>>> SEVERE: Context startup failed due to previous errors
>>>>
>>>> Where do I need to configure the log4j? Is this the only problem   
>>>> stopping it from starting?
>>>>
>>>> 10x in advance
>>>>
>>>
>>>
>>>
>
>
>

-- 
Nothing is particulary hard if you divide it into small jobs. (Henry Ford)

Hi,

Can you explain what the issue was? So we can keep track and maybe add it  
to a FAQ or the install notes.

Next steps are as described in the Readme.txt:
- create the database tables
- create a first user (this becomes the admin user)
- create a project
- create issues

Cheers

-- Eric.

On Sat, 26 Jun 2004 02:37:33 +0300, pope <apo...@ez...> wrote:

>
> 10x for the hints. i've solved this issue and i got the 1st page. what  
> next? :-)
>
> [Have a nice day] / [10x]
> ---
> Pope
> ---
> <<There are only solutions...>>
>
> [Have a nice day] / [10x]
> ---
> Pope
> ---
> <<There are only solutions...>>
>
>
>
> Eric Pieters wrote:
>
>> Not sure if you are registered on menda-dev, so here it is again.
>>
>> -- Eric.
>>
>> ------- Forwarded message -------
>> From: "Eric Pieters" <eri...@ea...>
>> To: Men...@li...
>> Subject: Re: [Menda-developers] tomcat deploy
>> Date: Sat, 26 Jun 2004 00:23:10 +0200
>>
>> Hi,
>>
>> I assume you checked out the latest menda code from CVS.
>>
>> 1. Check if you have the file log4j.properties in the following  
>> location:
>> <MENDA_HOME>\src\resources\log4j.properties
>> <MENDA_HOME>\src\webapp\WEB_INF\classes\log4j.properties
>> <TOMCAT_HOME>\webapps\menda\WEB-INF\classes\log4j.properties
>>
>> 2. Run ant help, capture the output and email it to menda-dev.
>> 3. Please also run ant -verbose deploy.war, capture the output and email
>> it to menda-dev.
>>
>> That will give us some materials to start investigating the problem.
>>
>> Thanks.
>>
>> -- Eric.
>>
>>
>>
>> On Sat, 26 Jun 2004 00:29:24 +0300, pope <apo...@ez...> wrote:
>>
>>> Hi!
>>>
>>> I am trying to deploy the war using the ant target on Tomcat 5.0.18.  
>>> But  Tomcat complains:
>>> INFO:   
>>> validateJarFile(C:\java\progs\tomcat-5.0.18\webapps\menda\WEB-INF\lib\servlet.jar)   
>>> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
>>>  javax/servlet/Servlet.class
>>> log4j:WARN No appenders could be found for logger   
>>> (org.apache.commons.digester.Digester).
>>> log4j:WARN Please initialize the log4j system properly.
>>> Jun 26, 2004 12:20:12 AM org.apache.catalina.core.StandardContext start
>>> SEVERE: Error listenerStart
>>> Jun 26, 2004 12:20:12 AM org.apache.catalina.core.StandardContext start
>>> SEVERE: Context startup failed due to previous errors
>>>
>>> Where do I need to configure the log4j? Is this the only problem   
>>> stopping it from starting?
>>>
>>> 10x in advance
>>>
>>
>>
>>

-- 
Nothing is particulary hard if you divide it into small jobs. (Henry Ford)

Tanel Lebedev wrote:
> I was hoping there exists some automatic tool for update. However I'm
> using hibernator plugin and it simply drops database and recreates it when
> one hits 'update schema' button :) so maybe there is no such thing in
> hibernate.

What about solving db-update through a porting utility?

We will need 2 database schemas (the old and the new one), but since we 
will have to develop a porting utility all the same it would be easier 
to just add (eg) a new "menda 1.x" possible porting source to it than to 
develop a whole new tool.

Besides, does anyone know if it is possible to have two hibernates 
running with two mappings for the same classes and connecting to two 
different databases?

If this is possible, writing a porting-client would maybe be a matter of 
reading the whole old database into objects, manipulating them (eg. to 
fill fields required by menda but not by the old source) and marshalling 
them to the new one...

Cheers,
	Giorgio

2004	Jan	Feb (15)	Mar (5)	Apr (7)	May (3)	Jun (102)	Jul (9)	Aug	Sep	Oct	Nov	Dec
2012	Jan	Feb	Mar	Apr (2)	May (3)	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May (1)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

menda-developers Mailing List for menda

menda-developers — Developers Discussion