cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: svn commit: r367382 - in /cocoon/trunk/lib: core/jetty-jmx-5.1.8.jar core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar jars.xml
Date Tue, 10 Jan 2006 08:45:53 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 10 Jan 2006, Leszek Gawron wrote:

> Date: Tue, 10 Jan 2006 09:23:46 +0100
> From: Leszek Gawron <lgawron@mobilebox.pl>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
>     core/jetty-jmx-5.1.8.jar   core/mx4j-3.0.1.jar core/mx4j-jmx-3.0.1.jar
>     jars.xml
> 
> Giacomo Pati wrote:
>>  -----BEGIN PGP SIGNED MESSAGE-----
>>  Hash: SHA1
>>
>>  On Tue, 10 Jan 2006, Leszek Gawron wrote:
>> 
>> >  Date: Tue, 10 Jan 2006 01:45:33 +0100
>> >  From: Leszek Gawron <lgawron@mobilebox.pl>
>> >  Reply-To: dev@cocoon.apache.org
>> >  To: dev@cocoon.apache.org
>> >  Subject: Re: svn commit: r367382 - in /cocoon/trunk/lib:
>> >      core/jetty-jmx-5.1.8.jar   core/mx4j-3.0.1.jar 
>> >  core/mx4j-jmx-3.0.1.jar
>> >      jars.xml
>> > 
>> >  Daniel Fagerstrom wrote:
>> > 
>> > >   Leszek Gawron skrev:
>> > > 
>> > > >   Daniel Fagerstrom wrote:
>> > > 
>> > >   ...
>> > > 
>> > > > >   I would prefer removing the trunk/lib and Ant build system
ASAP, 
>> > >  and > >  that everybody helps getting the parts they care for working

>> > >  with the > >  Maven build.
>> > > > > >   Before taking such drastic moves we should probably have
a 
>> > >  full >  replacement for current build system. Up till now we had quite

>> > >  a nice >  solution [1]. If we are to drop it we should resolve 
>> > >  following issues:
>> > > > >   1. developers/more advanced users often use trunk snapshots
even 
>> > >  for >  production (I have probably never used a released version :)).

>> > >  If so >  there has to be a support in our build system to deploy 
>> > >  artifacts not >  only to apache repository but also to 
>> > >  company's/individual's repository. >  I am not talking here about 
>> > >  simple 'mvn install' which only copies the >  file on the same 
>> > >  computer to local repo.
>> > > 
>> > > 
>> > >   The release plugin take care of this:
>> > >   http://maven.apache.org/guides/mini/guide-releasing.html, IIUC you 
>> > >   can
>> > >   overide where it reads from, I'm not shure about if there if you can
>> > >   override the release repository without changing the root POM.
>> > 
>> > 
>> >  The official documentation states the only way to do this is to change 
>> >  cocoon's POM and that is not a solution I would advise to users.
>>
>>
>>  I do not really understand the issue you are talking about (what would you
>>  like to deploy to your own repo? Cocoon itself?) But maybe have a look at
>>  the profile concept of Maven at
>>
>>  http://maven.apache.org/guides/introduction/introduction-to-profiles.html
>>
>>  A profile can be used similar to M1 build.properties but has much more
>>  possibilities (overwriting distribution management things).
> Yes I would like to deploy cocoon jars to my own repo. I do not want to rely 
> on snapshots held at cvs.apache.org because they might simply be deleted 
> (they're snapshots after all). In order to do that I will have to modify main 
> cocoon pom because these distributionManagement parameters may only be 
> included in pom. From the link you pointed:
>
> <quote>Depending on where you choose to configure your profile, you will have 
> access to varying POM configuration options. Profiles specified in external 
> files (i.e in settings.xml or profiles.xml) are not portable in the strictest 
> sense, because they externalize some of the build configuration from the only 
> project metadata that is maintained on the remote repositories: the POM. 
> Therefore, you will only be able to modify the repositories and 
> pluginRepositories sections of the POM, plus an extra properties 
> section.</quote>
>
> which means I cannot override distributionManagement config tag neither in 
> settings.xml nor in profiles.xml

You're right. The distributionManagement is not in the scope of an 
external profiles.xml. So, in your case you have to do what everybody is 
doing: sync the remote repos.

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDw3RHLNdJvZjjVZARAu9ZAKDdrqFoWa+N82XP/qe8OnkimZ5g2wCfQFBJ
OSxte7i/gkgHF9z6ACigDL8=
=t2eU
-----END PGP SIGNATURE-----

Mime
View raw message