You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Colin Chalmers <Co...@xs4all.nl> on 2003/09/10 20:47:13 UTC
Anyone building with Maven Beta 10
Hi,
When I first started building tonight I was getting loads of errors (>
100) complaining about missing classes. It actually boiled down to the
generation of the perr objects; the basePrefix is missing from the
project.properties whereby incorrect classNames were being generated for
the BasePeerObjects. By adding the following line to the maven
project.properties file
basePrefix = Base
the correct fileNames are generated and compilation can continue 't ill
the next 9 problems concerning Turbine Security classes (such as
TurbineUser & TurbineGroup) not implementing the save method. How are
these classes built, is there a template somewhere??
Colin
Re: Anyone building with Maven Beta 10
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Colin Chalmers <Co...@xs4all.nl> writes:
No. No updates to the project properties for this. The current Maven HEAD
actually works again (though there are other problems. See Issue MAVEN-690 for maven).
Martin, would it be possible that you somehow get MAVEN-690 into the
current maven HEAD? This would make it possible that the upcoming rc1
is able to build turbine.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: Torque Plugin Works..
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
Hurrah! Now let's hope that the maven people will tag some sort of
stable core to be rc1, so we might finally get a released maven
version that builds Turbine....
Regards
Henning
>Hi all,
>I just grabbed the torque plugin from CVS head of maven and it works. So
>you can build again!
>Eric
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Torque Plugin Works..
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
Hurrah! Now let's hope that the maven people will tag some sort of
stable core to be rc1, so we might finally get a released maven
version that builds Turbine....
Regards
Henning
>Hi all,
>I just grabbed the torque plugin from CVS head of maven and it works. So
>you can build again!
>Eric
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
No. We want to keep the order of the properties and I don't know whether
getSet() does this.
The underlying structure that uses addOnce() is rotten. This is
intended to be replaced with a
org.apache.commons.collections.decorators.OrderedSet once we have a
commons-collections release that contains this class.
Regards
Henning
>Hi all,
>I am looking at a chunk of code like this:
> Vector packages = Turbine.getConfiguration()
> .getVector(TurbineConstants.MODULE_PACKAGES);
> ObjectUtils.addOnce(packages,
> GenericLoader.getBasePackage());
>from Layout Loader...
>And it seems to me that commons-configuration getVector should be deprecated
>in favor of getSet(). I can't think why you would want duplicate values, so
>getSet() makes more sense then getList().
>Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
>Opinons? And do we have to deprecate getVector() since we haven't released
>from sandbox yet?
>Eric Pugh
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
No. We want to keep the order of the properties and I don't know whether
getSet() does this.
The underlying structure that uses addOnce() is rotten. This is
intended to be replaced with a
org.apache.commons.collections.decorators.OrderedSet once we have a
commons-collections release that contains this class.
Regards
Henning
>Hi all,
>I am looking at a chunk of code like this:
> Vector packages = Turbine.getConfiguration()
> .getVector(TurbineConstants.MODULE_PACKAGES);
> ObjectUtils.addOnce(packages,
> GenericLoader.getBasePackage());
>from Layout Loader...
>And it seems to me that commons-configuration getVector should be deprecated
>in favor of getSet(). I can't think why you would want duplicate values, so
>getSet() makes more sense then getList().
>Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
>Opinons? And do we have to deprecate getVector() since we haven't released
>from sandbox yet?
>Eric Pugh
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
AW: Torque Plugin Works..
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Eric,
I am trying to build jakarta-turbine-fulcrum with the torque plugin from
cvs head and get the following:
M:\eclipse\workspace\jakarta-turbine-fulcrum>maven torque:om-generate
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT
torque:init:
torque:om-generate:
[torque-data-model] Using classpath
log4j:ERROR Could not find value for key
log4j.appender.org.apache.torque.engine
log4j:ERROR Could not instantiate appender named
"org.apache.torque.engine".
[torque-data-model] Generating to file
M:\eclipse\workspace\jakarta-turbine-fulcrum\src\java\report.org.apache.
commons.grant.GrantProject@18330bf.om.generation
2003-09-17 12:51:25,657 [main] INFO
org.apache.torque.engine.database.transform.XmlToAppData - Parsing file:
'scheduler-schema.xml'
2003-09-17 12:51:25,687 [main] INFO
org.apache.torque.engine.database.transform.DTDResolver - Resolver: used
'http://jakarta.apache.org/turbine/dtd/database.dtd'
2003-09-17 12:51:27,039 [main] INFO
org.apache.torque.engine.database.transform.XmlToAppData - Parsing file:
'turbine-schema.xml'
2003-09-17 12:51:27,049 [main] INFO
org.apache.torque.engine.database.transform.DTDResolver - Resolver: used
'http://jakarta.apache.org/turbine/dtd/database.dtd'
BUILD FAILED
File...... file:/D:/Dokumente und
Einstellungen/buddy.BUDDYXP/.maven/plugins/maven-torque-plugin-3.2-SNAPS
HOT/
Element... torque-data-model
Line...... 228
Column.... 49
Exception thrown by 'properties.load'. For more information consult the
velocity log, or invoke ant with the -debug flag.
Total time: 8 seconds
Finished at: Wed Sep 17 12:51:27 CEST 2003
M:\eclipse\workspace\jakarta-turbine-fulcrum>
Kind regards
Jürgen Hoffmann
-----Ursprüngliche Nachricht-----
Von: Eric Pugh [mailto:epugh@upstate.com]
Gesendet: Mittwoch, 17. September 2003 09:36
An: 'Turbine Developers List'
Betreff: Torque Plugin Works..
Hi all,
I just grabbed the torque plugin from CVS head of maven and it works.
So
you can build again!
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
AW: Torque Plugin Works..
Posted by Jürgen Hoffmann <jh...@byteaction.de>.
Hi Eric,
I am trying to build jakarta-turbine-fulcrum with the torque plugin from
cvs head and get the following:
M:\eclipse\workspace\jakarta-turbine-fulcrum>maven torque:om-generate
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0-rc1-SNAPSHOT
torque:init:
torque:om-generate:
[torque-data-model] Using classpath
log4j:ERROR Could not find value for key
log4j.appender.org.apache.torque.engine
log4j:ERROR Could not instantiate appender named
"org.apache.torque.engine".
[torque-data-model] Generating to file
M:\eclipse\workspace\jakarta-turbine-fulcrum\src\java\report.org.apache.
commons.grant.GrantProject@18330bf.om.generation
2003-09-17 12:51:25,657 [main] INFO
org.apache.torque.engine.database.transform.XmlToAppData - Parsing file:
'scheduler-schema.xml'
2003-09-17 12:51:25,687 [main] INFO
org.apache.torque.engine.database.transform.DTDResolver - Resolver: used
'http://jakarta.apache.org/turbine/dtd/database.dtd'
2003-09-17 12:51:27,039 [main] INFO
org.apache.torque.engine.database.transform.XmlToAppData - Parsing file:
'turbine-schema.xml'
2003-09-17 12:51:27,049 [main] INFO
org.apache.torque.engine.database.transform.DTDResolver - Resolver: used
'http://jakarta.apache.org/turbine/dtd/database.dtd'
BUILD FAILED
File...... file:/D:/Dokumente und
Einstellungen/buddy.BUDDYXP/.maven/plugins/maven-torque-plugin-3.2-SNAPS
HOT/
Element... torque-data-model
Line...... 228
Column.... 49
Exception thrown by 'properties.load'. For more information consult the
velocity log, or invoke ant with the -debug flag.
Total time: 8 seconds
Finished at: Wed Sep 17 12:51:27 CEST 2003
M:\eclipse\workspace\jakarta-turbine-fulcrum>
Kind regards
Jürgen Hoffmann
-----Ursprüngliche Nachricht-----
Von: Eric Pugh [mailto:epugh@upstate.com]
Gesendet: Mittwoch, 17. September 2003 09:36
An: 'Turbine Developers List'
Betreff: Torque Plugin Works..
Hi all,
I just grabbed the torque plugin from CVS head of maven and it works.
So
you can build again!
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Torque Plugin Works..
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I just grabbed the torque plugin from CVS head of maven and it works. So
you can build again!
Eric
Torque Plugin Works..
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I just grabbed the torque plugin from CVS head of maven and it works. So
you can build again!
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: [configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Is getCollection what is wanted, or getList()?
I was under the impression that a collection isn't ordered.. And then you
would have to cast to a List to pass the collection into anything that
expects an ordered list.
Eric
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Thursday, September 25, 2003 10:02 AM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [configuration] Change Commons-Configuration getVector to
> getSet?
>
>
> Emmanuel Bourg <e....@cross-systems.com> writes:
>
> >--------------ms080101070400050103080207
> >Content-Type: text/plain; charset=us-ascii; format=flowed
> >Content-Transfer-Encoding: 7bit
>
> >A Set is too restrictive i think, there are valid reasons
> for preserving
> >duplicate configuration entries. I would use a Collection or
> better, a
> >List when the element order matters.
>
> -1 on using a set
>
> -1 on deprecating getVector()
>
> +1 on using a Collection
>
> +1 on getCollection()
>
> I have use cases, where I need repeating keys in the sequence that was
> put into the configuration file
>
> - sequence: list org service.<xxxx> keys in turbine.properties
>
> - repeating keys: list of packages to search for an action/screen
> in turbine.properties (here I need the
> exact sequence, too)
>
> So changing this API to use a set without order would damage the
> current Turbine code (which might be one of the main users of
> commons-configuration).
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> "Dominate!! Dominate!! Eat your young and aggregate! I have
> grotty silicon!"
> -- AOL CD when played backwards (User Friendly - 200-10-15)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Is getCollection what is wanted, or getList()?
I was under the impression that a collection isn't ordered.. And then you
would have to cast to a List to pass the collection into anything that
expects an ordered list.
Eric
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Thursday, September 25, 2003 10:02 AM
> To: commons-dev@jakarta.apache.org
> Subject: Re: [configuration] Change Commons-Configuration getVector to
> getSet?
>
>
> Emmanuel Bourg <e....@cross-systems.com> writes:
>
> >--------------ms080101070400050103080207
> >Content-Type: text/plain; charset=us-ascii; format=flowed
> >Content-Transfer-Encoding: 7bit
>
> >A Set is too restrictive i think, there are valid reasons
> for preserving
> >duplicate configuration entries. I would use a Collection or
> better, a
> >List when the element order matters.
>
> -1 on using a set
>
> -1 on deprecating getVector()
>
> +1 on using a Collection
>
> +1 on getCollection()
>
> I have use cases, where I need repeating keys in the sequence that was
> put into the configuration file
>
> - sequence: list org service.<xxxx> keys in turbine.properties
>
> - repeating keys: list of packages to search for an action/screen
> in turbine.properties (here I need the
> exact sequence, too)
>
> So changing this API to use a set without order would damage the
> current Turbine code (which might be one of the main users of
> commons-configuration).
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> "Dominate!! Dominate!! Eat your young and aggregate! I have
> grotty silicon!"
> -- AOL CD when played backwards (User Friendly - 200-10-15)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <e....@cross-systems.com> writes:
>--------------ms080101070400050103080207
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>A Set is too restrictive i think, there are valid reasons for preserving
>duplicate configuration entries. I would use a Collection or better, a
>List when the element order matters.
-1 on using a set
-1 on deprecating getVector()
+1 on using a Collection
+1 on getCollection()
I have use cases, where I need repeating keys in the sequence that was
put into the configuration file
- sequence: list org service.<xxxx> keys in turbine.properties
- repeating keys: list of packages to search for an action/screen
in turbine.properties (here I need the exact sequence, too)
So changing this API to use a set without order would damage the
current Turbine code (which might be one of the main users of
commons-configuration).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <e....@cross-systems.com> writes:
>A Set is too restrictive i think, there are valid reasons for preserving
>duplicate configuration entries. I would use a Collection or better, a
>List when the element order matters.
Definitely. I have several cases where I need multiple values for a key.
I thought that Eric was talking about MODULE_PACKAGES, where a set is
useful, but the sequence of packages must be preserved!
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <e....@cross-systems.com> writes:
>--------------ms080101070400050103080207
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>A Set is too restrictive i think, there are valid reasons for preserving
>duplicate configuration entries. I would use a Collection or better, a
>List when the element order matters.
-1 on using a set
-1 on deprecating getVector()
+1 on using a Collection
+1 on getCollection()
I have use cases, where I need repeating keys in the sequence that was
put into the configuration file
- sequence: list org service.<xxxx> keys in turbine.properties
- repeating keys: list of packages to search for an action/screen
in turbine.properties (here I need the exact sequence, too)
So changing this API to use a set without order would damage the
current Turbine code (which might be one of the main users of
commons-configuration).
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Emmanuel Bourg <e....@cross-systems.com> writes:
>A Set is too restrictive i think, there are valid reasons for preserving
>duplicate configuration entries. I would use a Collection or better, a
>List when the element order matters.
Definitely. I have several cases where I need multiple values for a key.
I thought that Eric was talking about MODULE_PACKAGES, where a set is
useful, but the sequence of packages must be preserved!
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
RE: [configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Re: [configuration] Change Commons-Configuration getVector to getSet?Out of
curiosity, what would be a usecase for multiple duplicate config entries
that are the same? Maybe to count them or something? So, does anyone have
an opinion on List? I definitly can understand why the Set wouldn't work.
I suggested Set thinking order didn't matter, but you are right, it does..
I guess I just don't like the look of Vector in things...
Eric
-----Original Message-----
From: Emmanuel Bourg [mailto:e.bourg@cross-systems.com]
Sent: Wednesday, September 17, 2003 2:45 PM
To: Jakarta Commons Developers List
Cc: 'Turbine Developers List'
Subject: Re: [configuration] Change Commons-Configuration getVector to
getSet?
A Set is too restrictive i think, there are valid reasons for preserving
duplicate configuration entries. I would use a Collection or better, a
List when the element order matters.
Emmanuel
Eric Pugh wrote:
> Hi all,
>
> I am looking at a chunk of code like this:
> Vector packages = Turbine.getConfiguration()
> .getVector(TurbineConstants.MODULE_PACKAGES);
>
> ObjectUtils.addOnce(packages,
> GenericLoader.getBasePackage());
>
> from Layout Loader...
>
> And it seems to me that commons-configuration getVector should be
deprecated
> in favor of getSet(). I can't think why you would want duplicate
values, so
> getSet() makes more sense then getList().
>
> Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
>
> Opinons? And do we have to deprecate getVector() since we haven't
released
> from sandbox yet?
>
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by Emmanuel Bourg <e....@cross-systems.com>.
A Set is too restrictive i think, there are valid reasons for preserving
duplicate configuration entries. I would use a Collection or better, a
List when the element order matters.
Emmanuel
Eric Pugh wrote:
> Hi all,
>
> I am looking at a chunk of code like this:
> Vector packages = Turbine.getConfiguration()
> .getVector(TurbineConstants.MODULE_PACKAGES);
>
> ObjectUtils.addOnce(packages,
> GenericLoader.getBasePackage());
>
> from Layout Loader...
>
> And it seems to me that commons-configuration getVector should be deprecated
> in favor of getSet(). I can't think why you would want duplicate values, so
> getSet() makes more sense then getList().
>
> Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
>
> Opinons? And do we have to deprecate getVector() since we haven't released
> from sandbox yet?
>
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [configuration] Change Commons-Configuration getVector to getSet?
Posted by Emmanuel Bourg <e....@cross-systems.com>.
A Set is too restrictive i think, there are valid reasons for preserving
duplicate configuration entries. I would use a Collection or better, a
List when the element order matters.
Emmanuel
Eric Pugh wrote:
> Hi all,
>
> I am looking at a chunk of code like this:
> Vector packages = Turbine.getConfiguration()
> .getVector(TurbineConstants.MODULE_PACKAGES);
>
> ObjectUtils.addOnce(packages,
> GenericLoader.getBasePackage());
>
> from Layout Loader...
>
> And it seems to me that commons-configuration getVector should be deprecated
> in favor of getSet(). I can't think why you would want duplicate values, so
> getSet() makes more sense then getList().
>
> Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
>
> Opinons? And do we have to deprecate getVector() since we haven't released
> from sandbox yet?
>
> Eric Pugh
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
[configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I am looking at a chunk of code like this:
Vector packages = Turbine.getConfiguration()
.getVector(TurbineConstants.MODULE_PACKAGES);
ObjectUtils.addOnce(packages,
GenericLoader.getBasePackage());
from Layout Loader...
And it seems to me that commons-configuration getVector should be deprecated
in favor of getSet(). I can't think why you would want duplicate values, so
getSet() makes more sense then getList().
Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
Opinons? And do we have to deprecate getVector() since we haven't released
from sandbox yet?
Eric Pugh
[configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I am looking at a chunk of code like this:
Vector packages = Turbine.getConfiguration()
.getVector(TurbineConstants.MODULE_PACKAGES);
ObjectUtils.addOnce(packages,
GenericLoader.getBasePackage());
from Layout Loader...
And it seems to me that commons-configuration getVector should be deprecated
in favor of getSet(). I can't think why you would want duplicate values, so
getSet() makes more sense then getList().
Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
Opinons? And do we have to deprecate getVector() since we haven't released
from sandbox yet?
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
[configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I am looking at a chunk of code like this:
Vector packages = Turbine.getConfiguration()
.getVector(TurbineConstants.MODULE_PACKAGES);
ObjectUtils.addOnce(packages,
GenericLoader.getBasePackage());
from Layout Loader...
And it seems to me that commons-configuration getVector should be deprecated
in favor of getSet(). I can't think why you would want duplicate values, so
getSet() makes more sense then getList().
Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
Opinons? And do we have to deprecate getVector() since we haven't released
from sandbox yet?
Eric Pugh
[configuration] Change Commons-Configuration getVector to getSet?
Posted by Eric Pugh <ep...@upstate.com>.
Hi all,
I am looking at a chunk of code like this:
Vector packages = Turbine.getConfiguration()
.getVector(TurbineConstants.MODULE_PACKAGES);
ObjectUtils.addOnce(packages,
GenericLoader.getBasePackage());
from Layout Loader...
And it seems to me that commons-configuration getVector should be deprecated
in favor of getSet(). I can't think why you would want duplicate values, so
getSet() makes more sense then getList().
Then, funky call's like the ObjectUtils.addOnce() wouldn't be needed...
Opinons? And do we have to deprecate getVector() since we haven't released
from sandbox yet?
Eric Pugh
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Anyone building with Maven Beta 10
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henning P. Schmiedehausen wrote:
...
> Yes, I want to have Fulcrum (I still don't like the name, BTW) to be
> something more or less turbine independent (if it makes sense to use
> some of the components outside of Turbine is another discussion, but I
> don't want to have "deep coupling" as we have now.
I agree that Fulcrum (I like the name ;) should be completely
independent of Turbine. Death to coupling.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Anyone building with Maven Beta 10
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Henning P. Schmiedehausen wrote:
...
> Yes, I want to have Fulcrum (I still don't like the name, BTW) to be
> something more or less turbine independent (if it makes sense to use
> some of the components outside of Turbine is another discussion, but I
> don't want to have "deep coupling" as we have now.
I agree that Fulcrum (I like the name ;) should be completely
independent of Turbine. Death to coupling.
- Dan
Re: Anyone building with Maven Beta 10
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>I guess on the flip side on this issue is that the various fulcrum
>components are very reusable in a non Turbine environment. Do we want to
>make what are supposed to be environment agnostic components requiring just
>Avalon to also have a requirement on Turbine?
Well,
as I said before, I consider the "pull" part of Turbine another
component in itself which will simply expose some tool interfaces
based on the Avalon lifecycle. So these components will have tools
that implement these interfaces.
In the end, I hope to have a turbine-independent pull system.
Yes, I want to have Fulcrum (I still don't like the name, BTW) to be
something more or less turbine independent (if it makes sense to use
some of the components outside of Turbine is another discussion, but I
don't want to have "deep coupling" as we have now.
Regards
Henning
>While one turbine jar that depends on two dozen different external jars to
>compile is part of the job of the Turbine developers. If we can't get our
>build of turbine to work with all the various tools that are supposed to
>work with Turbine, then how can we expect others?
>I personally think that none of the components in the fulcrum repo should
>have a Turbine dependency. Turbine should depend on them, not the other way
>around.
>Or, but this seems the worst:
>Fulcrum Repo of Components
>Fulcrum Repo of Tools/Utils/Classes that are Turbine tweaked
>Turbine Repo
>I committed a nice little workflow tool in the workflow/example app
>primarily b/c I don't know where to put it.. If I put it in fulcrum
>workflow, then that has a dependency on Turbine. Especially since I don't
>see the workflow pull tool being useful anywhere else but in Turbine land.
>Eric
>> -----Original Message-----
>> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
>> Sent: Sunday, September 14, 2003 7:06 PM
>> To: turbine-dev@jakarta.apache.org
>> Subject: Re: Anyone building with Maven Beta 10
>>
>>
>> "Eric Pugh" <ep...@upstate.com> writes:
>>
>> >Actually, fulcrum is *sorta* required. I went and updated
>> the localization
>> >tool to pull in the fulcrum localization service. However, after
>> >discussion, I am going to back out my changes and add a
>> parralel tool.
>>
>> >Currently the debate is between putting the "tool" in
>> fulcrum-localization
>> >or in turbine.. I am going to try and get the changes
>> backed out today.
>>
>> >The jars are available on jakarta.apache.org/turbine/repo....
>>
>> You just found the main reason why I'd prefer the tool in the
>> component/fulcrum, not turbine. ;-)
>>
>> Consider a library with not just one but two dozens of components
>> which all have tools. What would you prefer:
>>
>> a) two dozen component jars which all depend on turbine and
>> contain their own tools.
>>
>> b) one turbine jar which depends on two dozen different
>> external jars because it needs them
>> to compile the tools in turbine.
>>
>> Now answer the following question: Which one is a maintenance
>> nightmare?
>>
>> [ ] a)
>> [ ] b)
>>
>> ;-)
>>
>> Regards
>> Henning
>>
>>
>>
>>
>> >Eric
>>
>> >> -----Original Message-----
>> >> From: Scott Eade [mailto:seade@backstagetech.com.au]
>> >> Sent: Thursday, September 11, 2003 9:26 AM
>> >> To: Turbine Developers List
>> >> Subject: Re: Anyone building with Maven Beta 10
>> >>
>> >>
>> >> Colin Chalmers wrote:
>> >>
>> >> > Although I can understandHenning's frustration I do think a
>> >> committer
>> >> > should update the project.properties file, otherwise others will
>> >> > stumble on this problem. I now only have one error stopping
>> >> the build
>> >> > taking place and that's a dependancy in LocalizationTool on the
>> >> > Fulcrum LocalizationService. Seems we need Fulocrum afterall.
>> >>
>> >> I guess there is no reason why a committer other than Henning
>> >> can't add
>> >> the necessary properties :-)
>> >>
>> >> I don't see how the fulcrum is required - I can build fine
>> without it
>> >> (2_3 branch that is - will be trying HEAD shortly.
>> >>
>> >> Cheers,
>> >>
>> >> Scott
>> >>
>> >> --
>> >> Scott Eade
>> >> Backstage Technologies Pty. Ltd.
>> >> http://www.backstagetech.com.au
>> >> seade@backstagetech.com.au
>> >> Mobile: +61 403 278 908
>> >>
>> >>
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail:
>> turbine-dev-help@jakarta.apache.org
>>
>>
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> >For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
>> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>>
>> Java, perl, Solaris, Linux, xSP Consulting, Web Services
>> freelance consultant -- Jakarta Turbine Development -- hero for hire
>>
>> "Dominate!! Dominate!! Eat your young and aggregate! I have
>> grotty silicon!"
>> -- AOL CD when played backwards (User Friendly - 200-10-15)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
RE: Anyone building with Maven Beta 10
Posted by Eric Pugh <ep...@upstate.com>.
I guess on the flip side on this issue is that the various fulcrum
components are very reusable in a non Turbine environment. Do we want to
make what are supposed to be environment agnostic components requiring just
Avalon to also have a requirement on Turbine?
While one turbine jar that depends on two dozen different external jars to
compile is part of the job of the Turbine developers. If we can't get our
build of turbine to work with all the various tools that are supposed to
work with Turbine, then how can we expect others?
I personally think that none of the components in the fulcrum repo should
have a Turbine dependency. Turbine should depend on them, not the other way
around.
Or, but this seems the worst:
Fulcrum Repo of Components
Fulcrum Repo of Tools/Utils/Classes that are Turbine tweaked
Turbine Repo
I committed a nice little workflow tool in the workflow/example app
primarily b/c I don't know where to put it.. If I put it in fulcrum
workflow, then that has a dependency on Turbine. Especially since I don't
see the workflow pull tool being useful anywhere else but in Turbine land.
Eric
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Sunday, September 14, 2003 7:06 PM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: Anyone building with Maven Beta 10
>
>
> "Eric Pugh" <ep...@upstate.com> writes:
>
> >Actually, fulcrum is *sorta* required. I went and updated
> the localization
> >tool to pull in the fulcrum localization service. However, after
> >discussion, I am going to back out my changes and add a
> parralel tool.
>
> >Currently the debate is between putting the "tool" in
> fulcrum-localization
> >or in turbine.. I am going to try and get the changes
> backed out today.
>
> >The jars are available on jakarta.apache.org/turbine/repo....
>
> You just found the main reason why I'd prefer the tool in the
> component/fulcrum, not turbine. ;-)
>
> Consider a library with not just one but two dozens of components
> which all have tools. What would you prefer:
>
> a) two dozen component jars which all depend on turbine and
> contain their own tools.
>
> b) one turbine jar which depends on two dozen different
> external jars because it needs them
> to compile the tools in turbine.
>
> Now answer the following question: Which one is a maintenance
> nightmare?
>
> [ ] a)
> [ ] b)
>
> ;-)
>
> Regards
> Henning
>
>
>
>
> >Eric
>
> >> -----Original Message-----
> >> From: Scott Eade [mailto:seade@backstagetech.com.au]
> >> Sent: Thursday, September 11, 2003 9:26 AM
> >> To: Turbine Developers List
> >> Subject: Re: Anyone building with Maven Beta 10
> >>
> >>
> >> Colin Chalmers wrote:
> >>
> >> > Although I can understandHenning's frustration I do think a
> >> committer
> >> > should update the project.properties file, otherwise others will
> >> > stumble on this problem. I now only have one error stopping
> >> the build
> >> > taking place and that's a dependancy in LocalizationTool on the
> >> > Fulcrum LocalizationService. Seems we need Fulocrum afterall.
> >>
> >> I guess there is no reason why a committer other than Henning
> >> can't add
> >> the necessary properties :-)
> >>
> >> I don't see how the fulcrum is required - I can build fine
> without it
> >> (2_3 branch that is - will be trying HEAD shortly.
> >>
> >> Cheers,
> >>
> >> Scott
> >>
> >> --
> >> Scott Eade
> >> Backstage Technologies Pty. Ltd.
> >> http://www.backstagetech.com.au
> >> seade@backstagetech.com.au
> >> Mobile: +61 403 278 908
> >>
> >>
> >>
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> turbine-dev-help@jakarta.apache.org
>
>
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> "Dominate!! Dominate!! Eat your young and aggregate! I have
> grotty silicon!"
> -- AOL CD when played backwards (User Friendly - 200-10-15)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Anyone building with Maven Beta 10
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Eric Pugh" <ep...@upstate.com> writes:
>Actually, fulcrum is *sorta* required. I went and updated the localization
>tool to pull in the fulcrum localization service. However, after
>discussion, I am going to back out my changes and add a parralel tool.
>Currently the debate is between putting the "tool" in fulcrum-localization
>or in turbine.. I am going to try and get the changes backed out today.
>The jars are available on jakarta.apache.org/turbine/repo....
You just found the main reason why I'd prefer the tool in the
component/fulcrum, not turbine. ;-)
Consider a library with not just one but two dozens of components
which all have tools. What would you prefer:
a) two dozen component jars which all depend on turbine and contain their own tools.
b) one turbine jar which depends on two dozen different external jars because it needs them
to compile the tools in turbine.
Now answer the following question: Which one is a maintenance nightmare?
[ ] a)
[ ] b)
;-)
Regards
Henning
>Eric
>> -----Original Message-----
>> From: Scott Eade [mailto:seade@backstagetech.com.au]
>> Sent: Thursday, September 11, 2003 9:26 AM
>> To: Turbine Developers List
>> Subject: Re: Anyone building with Maven Beta 10
>>
>>
>> Colin Chalmers wrote:
>>
>> > Although I can understandHenning's frustration I do think a
>> committer
>> > should update the project.properties file, otherwise others will
>> > stumble on this problem. I now only have one error stopping
>> the build
>> > taking place and that's a dependancy in LocalizationTool on the
>> > Fulcrum LocalizationService. Seems we need Fulocrum afterall.
>>
>> I guess there is no reason why a committer other than Henning
>> can't add
>> the necessary properties :-)
>>
>> I don't see how the fulcrum is required - I can build fine without it
>> (2_3 branch that is - will be trying HEAD shortly.
>>
>> Cheers,
>>
>> Scott
>>
>> --
>> Scott Eade
>> Backstage Technologies Pty. Ltd.
>> http://www.backstagetech.com.au
>> seade@backstagetech.com.au
>> Mobile: +61 403 278 908
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: Anyone building with Maven Beta 10
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Scott Eade <se...@backstagetech.com.au> writes:
>I guess there is no reason why a committer other than Henning can't add
>the necessary properties :-)
Mainly because I'll -1 it and actively work against it. For the stated
reasons. If we start working around build tool bugs, we get on a
slippery slope that leads to madness.
Much as it is cumbersome, I'd actually prefer someone to cough up a
stable build.xml to build the turbine code with ant. We don't need
site building and lots of fancy stuff for this. Just compiling the
code is enough.
You can look at my eclipse proposal for this, which basically is a
stripped down ant build.xml
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: Anyone building with Maven Beta 10
Posted by Colin Chalmers <Co...@xs4all.nl>.
Scott,
I guess there is no reason why a committer other than Henning can't add
the necessary properties :-)
I'd do it myself but I'm not a committer :-)
>
> I don't see how the fulcrum is required - I can build fine without it
> (2_3 branch that is - will be trying HEAD shortly.
You're right, checked out 2.3.1 got it building and almost completed my
dev environment, phew! Will look into Intake stuff after my weekend break.
Colin
>
>
> Cheers,
>
> Scott
>
Re: Anyone building with Maven Beta 10
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Scott Eade <se...@backstagetech.com.au> writes:
>Colin,
>Given the fulcrum dependency in HEAD, why don't you work on
>the TURBINE_2_3_BRANCH - I assume your immediate need is to
>work on the Intake DateString problem which needs to go in
>3.2.1 anyway.
Yes, this is a good suggestion. For people wanting to use 2.3 but
keeping up to date on bug fixes, the 2.3 branch is much better.
We even have nice source snapshots on
http://cvs.apache.org/dist/jakarta/turbine/nightly/jakarta-turbine-2.3/
(Hm, the link from the jakarta repository is broken. Must fix.)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
RE: Anyone building with Maven Beta 10
Posted by Eric Pugh <ep...@upstate.com>.
+1 to that suggestion.. I am using CVS head and find it quite good. I do
always make a quick copy of my maven dir first though!
Eric
> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:hps@intermeta.de]
> Sent: Sunday, September 14, 2003 7:10 PM
> To: turbine-dev@jakarta.apache.org
> Subject: Re: Anyone building with Maven Beta 10
>
>
> Colin Chalmers <Co...@xs4all.nl> writes:
>
> >Hi Eric,
>
> >I was (am) experiencing problems but they may be more to do
> with Maven
> >Beta 10 as a specific tag was not being recognised. I'll look into
> >building again later but I want to concentrate on turbine first, and
> >have a (long) weekend break .
>
> Actually, the current maven HEAD has less problems than the beta-10
> snapshot. It seems to me that the maven guys always chose the least
> stable state of their tree to release a snapshot. beta-8 sucked,
> beta-9 sucked, beta-10 sucked. I have a beta-9-dev and a beta-10-dev
> which I checked out in the development phase and a rc1-dev which are
> all three quite decent (much less trouble than the actually tagged
> versions).
>
> So I'd suggest that you simply fetch the HEAD from the CVS and build
> it. It's quite simple.
>
>
> Regards
> Henning
>
>
>
> >Colin
>
> >Eric Pugh wrote:
>
> >>If you are having exceptions building Fulcrum, please let
> me know.. And
> >>check out the building fulcrum doc,
> >>http://jakarta.apache.org/turbine/fulcrum/building.html
> about the one gotcha
> >>in building Fulcrum..
> >>
> >>I know how frustrating it is to build and not have it work,
> so I want to
> >>keep it clean.
> >>
> >>Eric
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Scott Eade [mailto:seade@backstagetech.com.au]
> >>>Sent: Thursday, September 11, 2003 12:50 PM
> >>>To: Turbine Developers List
> >>>Subject: Re: Anyone building with Maven Beta 10
> >>>
> >>>
> >>>Colin,
> >>>
> >>>Given the fulcrum dependency in HEAD, why don't you work on
> >>>the TURBINE_2_3_BRANCH - I assume your immediate need is to
> >>>work on the Intake DateString problem which needs to go in
> >>>3.2.1 anyway.
> >>>
> >>>Scott
> >>>
> >>>--
> >>>Scott Eade
> >>>Backstage Technologies Pty. Ltd.
> >>>http://www.backstagetech.com.au
> >>>
> >>>
> >>>Eric Pugh wrote:
> >>>
> >>>
> >>>
> >>>>Actually, fulcrum is *sorta* required. I went and updated
> >>>>
> >>>>
> >>>the localization
> >>>
> >>>
> >>>>tool to pull in the fulcrum localization service. However, after
> >>>>discussion, I am going to back out my changes and add a
> >>>>
> >>>>
> >>>parralel tool.
> >>>
> >>>
> >>>>Currently the debate is between putting the "tool" in
> >>>>
> >>>>
> >>>fulcrum-localization
> >>>
> >>>
> >>>>or in turbine.. I am going to try and get the changes
> >>>>
> >>>>
> >>>backed out today.
> >>>
> >>>
> >>>>The jars are available on jakarta.apache.org/turbine/repo....
> >>>>
> >>>>Eric
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Scott Eade [mailto:seade@backstagetech.com.au]
> >>>>>Sent: Thursday, September 11, 2003 9:26 AM
> >>>>>To: Turbine Developers List
> >>>>>Subject: Re: Anyone building with Maven Beta 10
> >>>>>
> >>>>>
> >>>>>Colin Chalmers wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Although I can understandHenning's frustration I do think a
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>committer
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>should update the project.properties file, otherwise others will
> >>>>>>stumble on this problem. I now only have one error stopping
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>the build
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>taking place and that's a dependancy in LocalizationTool on the
> >>>>>>Fulcrum LocalizationService. Seems we need Fulocrum afterall.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>I guess there is no reason why a committer other than Henning
> >>>>>can't add
> >>>>>the necessary properties :-)
> >>>>>
> >>>>>I don't see how the fulcrum is required - I can build fine
> >>>>>
> >>>>>
> >>>without it
> >>>
> >>>
> >>>>>(2_3 branch that is - will be trying HEAD shortly.
> >>>>>
> >>>>>Cheers,
> >>>>>
> >>>>>Scott
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>-----------------------------------------------------------
> ----------
> >>>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail:
> turbine-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
> >>
> >>
> >>
> >>
> >>
>
>
>
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
> hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
>
> Java, perl, Solaris, Linux, xSP Consulting, Web Services
> freelance consultant -- Jakarta Turbine Development -- hero for hire
>
> "Dominate!! Dominate!! Eat your young and aggregate! I have
> grotty silicon!"
> -- AOL CD when played backwards (User Friendly - 200-10-15)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Anyone building with Maven Beta 10
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Colin Chalmers <Co...@xs4all.nl> writes:
>Hi Eric,
>I was (am) experiencing problems but they may be more to do with Maven
>Beta 10 as a specific tag was not being recognised. I'll look into
>building again later but I want to concentrate on turbine first, and
>have a (long) weekend break .
Actually, the current maven HEAD has less problems than the beta-10
snapshot. It seems to me that the maven guys always chose the least
stable state of their tree to release a snapshot. beta-8 sucked,
beta-9 sucked, beta-10 sucked. I have a beta-9-dev and a beta-10-dev
which I checked out in the development phase and a rc1-dev which are
all three quite decent (much less trouble than the actually tagged
versions).
So I'd suggest that you simply fetch the HEAD from the CVS and build
it. It's quite simple.
Regards
Henning
>Colin
>Eric Pugh wrote:
>>If you are having exceptions building Fulcrum, please let me know.. And
>>check out the building fulcrum doc,
>>http://jakarta.apache.org/turbine/fulcrum/building.html about the one gotcha
>>in building Fulcrum..
>>
>>I know how frustrating it is to build and not have it work, so I want to
>>keep it clean.
>>
>>Eric
>>
>>
>>
>>>-----Original Message-----
>>>From: Scott Eade [mailto:seade@backstagetech.com.au]
>>>Sent: Thursday, September 11, 2003 12:50 PM
>>>To: Turbine Developers List
>>>Subject: Re: Anyone building with Maven Beta 10
>>>
>>>
>>>Colin,
>>>
>>>Given the fulcrum dependency in HEAD, why don't you work on
>>>the TURBINE_2_3_BRANCH - I assume your immediate need is to
>>>work on the Intake DateString problem which needs to go in
>>>3.2.1 anyway.
>>>
>>>Scott
>>>
>>>--
>>>Scott Eade
>>>Backstage Technologies Pty. Ltd.
>>>http://www.backstagetech.com.au
>>>
>>>
>>>Eric Pugh wrote:
>>>
>>>
>>>
>>>>Actually, fulcrum is *sorta* required. I went and updated
>>>>
>>>>
>>>the localization
>>>
>>>
>>>>tool to pull in the fulcrum localization service. However, after
>>>>discussion, I am going to back out my changes and add a
>>>>
>>>>
>>>parralel tool.
>>>
>>>
>>>>Currently the debate is between putting the "tool" in
>>>>
>>>>
>>>fulcrum-localization
>>>
>>>
>>>>or in turbine.. I am going to try and get the changes
>>>>
>>>>
>>>backed out today.
>>>
>>>
>>>>The jars are available on jakarta.apache.org/turbine/repo....
>>>>
>>>>Eric
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: Scott Eade [mailto:seade@backstagetech.com.au]
>>>>>Sent: Thursday, September 11, 2003 9:26 AM
>>>>>To: Turbine Developers List
>>>>>Subject: Re: Anyone building with Maven Beta 10
>>>>>
>>>>>
>>>>>Colin Chalmers wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Although I can understandHenning's frustration I do think a
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>committer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>should update the project.properties file, otherwise others will
>>>>>>stumble on this problem. I now only have one error stopping
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>the build
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>taking place and that's a dependancy in LocalizationTool on the
>>>>>>Fulcrum LocalizationService. Seems we need Fulocrum afterall.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>I guess there is no reason why a committer other than Henning
>>>>>can't add
>>>>>the necessary properties :-)
>>>>>
>>>>>I don't see how the fulcrum is required - I can build fine
>>>>>
>>>>>
>>>without it
>>>
>>>
>>>>>(2_3 branch that is - will be trying HEAD shortly.
>>>>>
>>>>>Cheers,
>>>>>
>>>>>Scott
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
"Dominate!! Dominate!! Eat your young and aggregate! I have grotty silicon!"
-- AOL CD when played backwards (User Friendly - 200-10-15)
Re: Anyone building with Maven Beta 10
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Eric,
I was (am) experiencing problems but they may be more to do with Maven
Beta 10 as a specific tag was not being recognised. I'll look into
building again later but I want to concentrate on turbine first, and
have a (long) weekend break .
Colin
Eric Pugh wrote:
>If you are having exceptions building Fulcrum, please let me know.. And
>check out the building fulcrum doc,
>http://jakarta.apache.org/turbine/fulcrum/building.html about the one gotcha
>in building Fulcrum..
>
>I know how frustrating it is to build and not have it work, so I want to
>keep it clean.
>
>Eric
>
>
>
>>-----Original Message-----
>>From: Scott Eade [mailto:seade@backstagetech.com.au]
>>Sent: Thursday, September 11, 2003 12:50 PM
>>To: Turbine Developers List
>>Subject: Re: Anyone building with Maven Beta 10
>>
>>
>>Colin,
>>
>>Given the fulcrum dependency in HEAD, why don't you work on
>>the TURBINE_2_3_BRANCH - I assume your immediate need is to
>>work on the Intake DateString problem which needs to go in
>>3.2.1 anyway.
>>
>>Scott
>>
>>--
>>Scott Eade
>>Backstage Technologies Pty. Ltd.
>>http://www.backstagetech.com.au
>>
>>
>>Eric Pugh wrote:
>>
>>
>>
>>>Actually, fulcrum is *sorta* required. I went and updated
>>>
>>>
>>the localization
>>
>>
>>>tool to pull in the fulcrum localization service. However, after
>>>discussion, I am going to back out my changes and add a
>>>
>>>
>>parralel tool.
>>
>>
>>>Currently the debate is between putting the "tool" in
>>>
>>>
>>fulcrum-localization
>>
>>
>>>or in turbine.. I am going to try and get the changes
>>>
>>>
>>backed out today.
>>
>>
>>>The jars are available on jakarta.apache.org/turbine/repo....
>>>
>>>Eric
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Scott Eade [mailto:seade@backstagetech.com.au]
>>>>Sent: Thursday, September 11, 2003 9:26 AM
>>>>To: Turbine Developers List
>>>>Subject: Re: Anyone building with Maven Beta 10
>>>>
>>>>
>>>>Colin Chalmers wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Although I can understandHenning's frustration I do think a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>committer
>>>>
>>>>
>>>>
>>>>
>>>>>should update the project.properties file, otherwise others will
>>>>>stumble on this problem. I now only have one error stopping
>>>>>
>>>>>
>>>>>
>>>>>
>>>>the build
>>>>
>>>>
>>>>
>>>>
>>>>>taking place and that's a dependancy in LocalizationTool on the
>>>>>Fulcrum LocalizationService. Seems we need Fulocrum afterall.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>I guess there is no reason why a committer other than Henning
>>>>can't add
>>>>the necessary properties :-)
>>>>
>>>>I don't see how the fulcrum is required - I can build fine
>>>>
>>>>
>>without it
>>
>>
>>>>(2_3 branch that is - will be trying HEAD shortly.
>>>>
>>>>Cheers,
>>>>
>>>>Scott
>>>>
>>>>
>>>>
>>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
>
RE: Anyone building with Maven Beta 10
Posted by Eric Pugh <ep...@upstate.com>.
If you are having exceptions building Fulcrum, please let me know.. And
check out the building fulcrum doc,
http://jakarta.apache.org/turbine/fulcrum/building.html about the one gotcha
in building Fulcrum..
I know how frustrating it is to build and not have it work, so I want to
keep it clean.
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Thursday, September 11, 2003 12:50 PM
> To: Turbine Developers List
> Subject: Re: Anyone building with Maven Beta 10
>
>
> Colin,
>
> Given the fulcrum dependency in HEAD, why don't you work on
> the TURBINE_2_3_BRANCH - I assume your immediate need is to
> work on the Intake DateString problem which needs to go in
> 3.2.1 anyway.
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
>
>
> Eric Pugh wrote:
>
> >Actually, fulcrum is *sorta* required. I went and updated
> the localization
> >tool to pull in the fulcrum localization service. However, after
> >discussion, I am going to back out my changes and add a
> parralel tool.
> >
> >Currently the debate is between putting the "tool" in
> fulcrum-localization
> >or in turbine.. I am going to try and get the changes
> backed out today.
> >
> >The jars are available on jakarta.apache.org/turbine/repo....
> >
> >Eric
> >
> >
> >
> >>-----Original Message-----
> >>From: Scott Eade [mailto:seade@backstagetech.com.au]
> >>Sent: Thursday, September 11, 2003 9:26 AM
> >>To: Turbine Developers List
> >>Subject: Re: Anyone building with Maven Beta 10
> >>
> >>
> >>Colin Chalmers wrote:
> >>
> >>
> >>
> >>>Although I can understandHenning's frustration I do think a
> >>>
> >>>
> >>committer
> >>
> >>
> >>>should update the project.properties file, otherwise others will
> >>>stumble on this problem. I now only have one error stopping
> >>>
> >>>
> >>the build
> >>
> >>
> >>>taking place and that's a dependancy in LocalizationTool on the
> >>>Fulcrum LocalizationService. Seems we need Fulocrum afterall.
> >>>
> >>>
> >>I guess there is no reason why a committer other than Henning
> >>can't add
> >>the necessary properties :-)
> >>
> >>I don't see how the fulcrum is required - I can build fine
> without it
> >>(2_3 branch that is - will be trying HEAD shortly.
> >>
> >>Cheers,
> >>
> >>Scott
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Anyone building with Maven Beta 10
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin,
Given the fulcrum dependency in HEAD, why don't you work on
the TURBINE_2_3_BRANCH - I assume your immediate need is to
work on the Intake DateString problem which needs to go in
3.2.1 anyway.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
Eric Pugh wrote:
>Actually, fulcrum is *sorta* required. I went and updated the localization
>tool to pull in the fulcrum localization service. However, after
>discussion, I am going to back out my changes and add a parralel tool.
>
>Currently the debate is between putting the "tool" in fulcrum-localization
>or in turbine.. I am going to try and get the changes backed out today.
>
>The jars are available on jakarta.apache.org/turbine/repo....
>
>Eric
>
>
>
>>-----Original Message-----
>>From: Scott Eade [mailto:seade@backstagetech.com.au]
>>Sent: Thursday, September 11, 2003 9:26 AM
>>To: Turbine Developers List
>>Subject: Re: Anyone building with Maven Beta 10
>>
>>
>>Colin Chalmers wrote:
>>
>>
>>
>>>Although I can understandHenning's frustration I do think a
>>>
>>>
>>committer
>>
>>
>>>should update the project.properties file, otherwise others will
>>>stumble on this problem. I now only have one error stopping
>>>
>>>
>>the build
>>
>>
>>>taking place and that's a dependancy in LocalizationTool on the
>>>Fulcrum LocalizationService. Seems we need Fulocrum afterall.
>>>
>>>
>>I guess there is no reason why a committer other than Henning
>>can't add
>>the necessary properties :-)
>>
>>I don't see how the fulcrum is required - I can build fine without it
>>(2_3 branch that is - will be trying HEAD shortly.
>>
>>Cheers,
>>
>>Scott
>>
>>
RE: Anyone building with Maven Beta 10
Posted by Eric Pugh <ep...@upstate.com>.
Actually, fulcrum is *sorta* required. I went and updated the localization
tool to pull in the fulcrum localization service. However, after
discussion, I am going to back out my changes and add a parralel tool.
Currently the debate is between putting the "tool" in fulcrum-localization
or in turbine.. I am going to try and get the changes backed out today.
The jars are available on jakarta.apache.org/turbine/repo....
Eric
> -----Original Message-----
> From: Scott Eade [mailto:seade@backstagetech.com.au]
> Sent: Thursday, September 11, 2003 9:26 AM
> To: Turbine Developers List
> Subject: Re: Anyone building with Maven Beta 10
>
>
> Colin Chalmers wrote:
>
> > Although I can understandHenning's frustration I do think a
> committer
> > should update the project.properties file, otherwise others will
> > stumble on this problem. I now only have one error stopping
> the build
> > taking place and that's a dependancy in LocalizationTool on the
> > Fulcrum LocalizationService. Seems we need Fulocrum afterall.
>
> I guess there is no reason why a committer other than Henning
> can't add
> the necessary properties :-)
>
> I don't see how the fulcrum is required - I can build fine without it
> (2_3 branch that is - will be trying HEAD shortly.
>
> Cheers,
>
> Scott
>
> --
> Scott Eade
> Backstage Technologies Pty. Ltd.
> http://www.backstagetech.com.au
> seade@backstagetech.com.au
> Mobile: +61 403 278 908
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Anyone building with Maven Beta 10
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> Although I can understandHenning's frustration I do think a committer
> should update the project.properties file, otherwise others will
> stumble on this problem. I now only have one error stopping the build
> taking place and that's a dependancy in LocalizationTool on the
> Fulcrum LocalizationService. Seems we need Fulocrum afterall.
I guess there is no reason why a committer other than Henning can't add
the necessary properties :-)
I don't see how the fulcrum is required - I can build fine without it
(2_3 branch that is - will be trying HEAD shortly.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
seade@backstagetech.com.au
Mobile: +61 403 278 908
Re: Anyone building with Maven Beta 10
Posted by Colin Chalmers <Co...@xs4all.nl>.
Hi Scott,
Thx for that, yeah things seem to work (better) now.
Although I can understandHenning's frustration I do think a committer
should update the project.properties file, otherwise others will stumble
on this problem. I now only have one error stopping the build taking
place and that's a dependancy in LocalizationTool on the Fulcrum
LocalizationService. Seems we need Fulocrum afterall.
Colin
Scott Eade wrote:
> Colin Chalmers wrote:
>
>> When I first started building tonight I was getting loads of errors
>> (> 100) complaining about missing classes. It actually boiled down to
>> the generation of the perr objects; the basePrefix is missing from
>> the project.properties whereby incorrect classNames were being
>> generated for the BasePeerObjects. By adding the following line to
>> the maven project.properties file
>>
>> basePrefix = Base
>>
>> the correct fileNames are generated and compilation can continue 't
>> ill the next 9 problems concerning Turbine Security classes (such as
>> TurbineUser & TurbineGroup) not implementing the save method. How
>> are these classes built, is there a template somewhere??
>
>
> It is in fact a maven problem - it is not picking up the default
> properties for the torque plugin. See:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgNo=14889
>
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgNo=15069
>
>
> BTW: You shouldn't need fulcrum to build turbine. Fulcrum HEAD is in
> a state of flux at present.
>
> Scott
>
Re: Anyone building with Maven Beta 10
Posted by Scott Eade <se...@backstagetech.com.au>.
Colin Chalmers wrote:
> When I first started building tonight I was getting loads of errors (>
> 100) complaining about missing classes. It actually boiled down to the
> generation of the perr objects; the basePrefix is missing from the
> project.properties whereby incorrect classNames were being generated
> for the BasePeerObjects. By adding the following line to the maven
> project.properties file
>
> basePrefix = Base
>
> the correct fileNames are generated and compilation can continue 't
> ill the next 9 problems concerning Turbine Security classes (such as
> TurbineUser & TurbineGroup) not implementing the save method. How are
> these classes built, is there a template somewhere??
It is in fact a maven problem - it is not picking up the default
properties for the torque plugin. See:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgNo=14889
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgNo=15069
BTW: You shouldn't need fulcrum to build turbine. Fulcrum HEAD is in a
state of flux at present.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
RE: Anyone building with Maven Beta 10
Posted by Eric Pugh <ep...@upstate.com>.
There was a post earlier about this.. Henning had the same issue and just
copied everything from the plugin.properties to the project.properties and
it worked for him. For me however it doesn't..
Half the reason to integrate fulcrum security and fulcrum sheduler is to get
rid of those build issues! Or at least move them elsewhere!
Eric
> -----Original Message-----
> From: Colin Chalmers [mailto:Colin.Chalmers@xs4all.nl]
> Sent: Wednesday, September 10, 2003 8:47 PM
> To: Turbine Developers List
> Subject: Anyone building with Maven Beta 10
>
>
> Hi,
>
> When I first started building tonight I was getting loads of
> errors (>
> 100) complaining about missing classes. It actually boiled
> down to the
> generation of the perr objects; the basePrefix is missing from the
> project.properties whereby incorrect classNames were being
> generated for
> the BasePeerObjects. By adding the following line to the maven
> project.properties file
>
> basePrefix = Base
>
> the correct fileNames are generated and compilation can
> continue 't ill
> the next 9 problems concerning Turbine Security classes (such as
> TurbineUser & TurbineGroup) not implementing the save method.
> How are
> these classes built, is there a template somewhere??
>
> Colin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org