You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/04/06 12:32:49 UTC
[all] Shared build causes issues in releases
Our maven scripts now depend on commons-build, however
this is of course not included in the release zips.
This is a problem and means that maven cannot be used
in releases.
Anyone got any ideas on how to solve this? I don't
like the idea of hacking project xml for each release.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I wasn't clear, I'm not adverse to doing that either.
-Mark
Jeffrey D. Brekke wrote:
> Couldn't the source releases just zip up the commons-build directory
> along with the projects. Maybe sprinkle a special goal in
> commons-build/maven.xml for this?
>
>
>>>>>>On Tue, 06 Apr 2004 09:06:20 -0400, "Mark R. Diggory" <md...@latte.harvard.edu> said:
>
>
>>I would argue that, while I consider Maven to be a great developer
>>tool for sites and testing, I do not consider it to be a great
>>"user" tool at this point, its too heavy. I would highly recommend a
>>Maven generated Ant build file for each project and Ant build file
>>that iterates over the common goals of these for the entire project.
>
>
>>1.) The issue of common dependencies could be resolved by
>>parameterizing things like the location that dependency jars are
>>downloaded to so that all scripts use the same location.
>
>
>>2.) I'm not impressed that anyone would ever want to download the
>>entire commons as a src zip and compile it. Its modularity, and its
>>separate release cycles for each module really make such an effort
>>have no value (IMHO). When I need a commons module, I go and get
>>just that module, thats the whole power of having everything
>>separate. Why would/should I compile that digester when all I wanted
>>was lang? I say keep things well separated, otherwise the user will
>>suffer.
>
>
>>-Mark
>
>
>
>>Stephen Colebourne wrote:
>>
>>>Our maven scripts now depend on commons-build, however this is of
>>>course not included in the release zips. This is a problem and
>>>means that maven cannot be used in releases. Anyone got any ideas
>>>on how to solve this? I don't like the idea of hacking project xml
>>>for each release. Stephen
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>commons-dev-help@jakarta.apache.org
>>>
>
>
>>-- Mark Diggory Software Developer Harvard MIT Data Center
>>http://www.hmdc.harvard.edu
>
>
>
>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by "Jeffrey D. Brekke" <jb...@wi.rr.com>.
Couldn't the source releases just zip up the commons-build directory
along with the projects. Maybe sprinkle a special goal in
commons-build/maven.xml for this?
>>>>> On Tue, 06 Apr 2004 09:06:20 -0400, "Mark R. Diggory" <md...@latte.harvard.edu> said:
> I would argue that, while I consider Maven to be a great developer
> tool for sites and testing, I do not consider it to be a great
> "user" tool at this point, its too heavy. I would highly recommend a
> Maven generated Ant build file for each project and Ant build file
> that iterates over the common goals of these for the entire project.
> 1.) The issue of common dependencies could be resolved by
> parameterizing things like the location that dependency jars are
> downloaded to so that all scripts use the same location.
> 2.) I'm not impressed that anyone would ever want to download the
> entire commons as a src zip and compile it. Its modularity, and its
> separate release cycles for each module really make such an effort
> have no value (IMHO). When I need a commons module, I go and get
> just that module, thats the whole power of having everything
> separate. Why would/should I compile that digester when all I wanted
> was lang? I say keep things well separated, otherwise the user will
> suffer.
> -Mark
> Stephen Colebourne wrote:
>> Our maven scripts now depend on commons-build, however this is of
>> course not included in the release zips. This is a problem and
>> means that maven cannot be used in releases. Anyone got any ideas
>> on how to solve this? I don't like the idea of hacking project xml
>> for each release. Stephen
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-dev-help@jakarta.apache.org
>>
> -- Mark Diggory Software Developer Harvard MIT Data Center
> http://www.hmdc.harvard.edu
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
=====================================================================
Jeffrey D. Brekke jbrekke@wi.rr.com
Wisconsin, USA brekke@apache.org
ekkerbj@yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 6 Apr 2004, Noel J. Bergman <no...@devtech.com> wrote:
> Mark R. Diggory wrote:
>
>> I would highly recommend a Maven generated Ant build file
>> for each project and Ant build file that iterates over
>> the common goals of these for the entire project.
>
> +1
>
> Can you help make that happen? :-)
Sounds more or less like a simple <subant>.
I've seen many "reactor-like" builds do that stuff with <antcall> and
maybe even <foreach> or something like that. The top level build file
could be something simple like
<project>
<macrodef name="delegate">
<attribute name="target">
<sequential>
<subant target="@{target}">
<fileset dir="." includes="**/build.xml"/>
</subant>
</sequential>
</macrodef>
<target name="jar">
<delegate target="jar"/>
</target>
<target name="dist">
<delegate target="dist"/>
</target>
...
</project>
That's stock Ant 1.6.x.
Yes, I know this could be even simpler if Ant provided programatic
access to the targetname it has been asked to run.
Cheers
Stefan
--
http://stefanbodewig.blogger.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [all] Shared build causes issues in releases
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mark R. Diggory wrote:
> I do not consider [Maven] to be a great "user" tool
> I would highly recommend a Maven generated Ant build file
> for each project and Ant build file that iterates over
> the common goals of these for the entire project.
+1
Can you help make that happen? :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I would argue that, while I consider Maven to be a great developer tool
for sites and testing, I do not consider it to be a great "user" tool at
this point, its too heavy. I would highly recommend a Maven generated
Ant build file for each project and Ant build file that iterates over
the common goals of these for the entire project.
1.) The issue of common dependencies could be resolved by parameterizing
things like the location that dependency jars are downloaded to so that
all scripts use the same location.
2.) I'm not impressed that anyone would ever want to download the entire
commons as a src zip and compile it. Its modularity, and its separate
release cycles for each module really make such an effort have no value
(IMHO). When I need a commons module, I go and get just that module,
thats the whole power of having everything separate. Why would/should I
compile that digester when all I wanted was lang? I say keep things well
separated, otherwise the user will suffer.
-Mark
Stephen Colebourne wrote:
> Our maven scripts now depend on commons-build, however
> this is of course not included in the release zips.
> This is a problem and means that maven cannot be used
> in releases.
>
> Anyone got any ideas on how to solve this? I don't
> like the idea of hacking project xml for each release.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I see your point differently now, but still come to the same conclusion,
I think the following:
1.) Individual commons project source distributions should use the
generated ant build.xml for compiling, testing and jaring.
2a.) If we distribute a src of the entire commons, it should have the
commons-build directory in it and directions on how to build using
either maven or the generated ant build.xml's.
2b.) We can take one of the generated ant build.xml's and gut it, place
it in /jakarta-commons/commons-build/build.xml, map each target in it to
run the same target in all the underlying generated subproject ant
build.xml files. This way the user can choose between ant or maven for
their build env.
On Tue, 2004-04-06 at 10:28, Stephen Colebourne wrote:
> --- "matthew.hawthorne" <ma...@apache.org> wrote: >
> Stephen Colebourne wrote:
> > > Our maven scripts now depend on commons-build,
> > however
> > > this is of course not included in the release
> > zips.
> > > This is a problem and means that maven cannot be
> > used
> > > in releases.
> >
> > How is this any different that before, when the
> > Maven scripts depended
> > on jakarta-commons/project.xml?
>
> It isn't, but its still wrong. The point is that it is
> difficult to obtain the commons-build/project.xml
> file. It can only be done via view-cvs really.
>
> Perhaps we could start by renaming project.xml in
> commons-build to project-common.xml. Then a release
> could copy it from commons-build to the individual
> project.
>
not to keen on renaming it, if you really want to explore doing this,
just rename it when you copy it into the local directory?
> Also, what about having the extends clause use a
> variable to define the location of commons-build. The
> default could be 'same folder' for releases.
>
not a bad idea, I didn't realize it was possible. The big issue I see
though with moving the commons-build/project.xml, is that is uses alot
of relative relationships in terms of configuration, simply just having
the project.xml extended to a local copy does not solve those
relationships.
Ultimately, it'd almost be more worthwhile to use something like an xslt
transform to merge the two project.xmls into one for the individual
source distro's. Then you remove any dependencies on the commons-build
area and extension issues go away.
> Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
--
Mark R. Diggory
Software Developer - VDC Project
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by Stephen Colebourne <sc...@btopenworld.com>.
--- "matthew.hawthorne" <ma...@apache.org> wrote: >
Stephen Colebourne wrote:
> > Our maven scripts now depend on commons-build,
> however
> > this is of course not included in the release
> zips.
> > This is a problem and means that maven cannot be
> used
> > in releases.
>
> How is this any different that before, when the
> Maven scripts depended
> on jakarta-commons/project.xml?
It isn't, but its still wrong. The point is that it is
difficult to obtain the commons-build/project.xml
file. It can only be done via view-cvs really.
Perhaps we could start by renaming project.xml in
commons-build to project-common.xml. Then a release
could copy it from commons-build to the individual
project.
Also, what about having the extends clause use a
variable to define the location of commons-build. The
default could be 'same folder' for releases.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by "matthew.hawthorne" <ma...@apache.org>.
Stephen Colebourne wrote:
> Our maven scripts now depend on commons-build, however
> this is of course not included in the release zips.
> This is a problem and means that maven cannot be used
> in releases.
How is this any different that before, when the Maven scripts depended
on jakarta-commons/project.xml?
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by Tim O'Brien <to...@discursive.com>.
Stephen, what about just bundling the generated ant build.xml writing a
good README which explains the situation.
Tim
On Tue, 6 Apr 2004, Henri Yandell wrote:
>
> Write a custom jakarta-commons-plugin which has a release goal which
> incorporates including the commons-build directory would be one option.
>
> Would love to do it, but heavily overcommitted to things atm :(
>
> The personal wossnames I mentioned in private email a few weeks back was
> the news that my wife is pregnant :)
Congrats Henri.
>
> Hen
>
> On Tue, 6 Apr 2004, [iso-8859-1] Stephen Colebourne wrote:
>
> > Our maven scripts now depend on commons-build, however
> > this is of course not included in the release zips.
> > This is a problem and means that maven cannot be used
> > in releases.
> >
> > Anyone got any ideas on how to solve this? I don't
> > like the idea of hacking project xml for each release.
> >
> > Stephen
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
--
----------------------
Tim O'Brien
Evanston, IL
(847) 863-7045
tobrien@discursive.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [all] Shared build causes issues in releases
Posted by Henri Yandell <ba...@generationjava.com>.
Write a custom jakarta-commons-plugin which has a release goal which
incorporates including the commons-build directory would be one option.
Would love to do it, but heavily overcommitted to things atm :(
The personal wossnames I mentioned in private email a few weeks back was
the news that my wife is pregnant :)
Hen
On Tue, 6 Apr 2004, [iso-8859-1] Stephen Colebourne wrote:
> Our maven scripts now depend on commons-build, however
> this is of course not included in the release zips.
> This is a problem and means that maven cannot be used
> in releases.
>
> Anyone got any ideas on how to solve this? I don't
> like the idea of hacking project xml for each release.
>
> Stephen
>
> ---------------------------------------------------------------------
> 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