pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Hi All,

Got a question about poms... Is there any reason why versions of some artifacts 
are hardcoded in some of the poms? Specific examples are [1]:

     <dependency>
       <groupId>org.apache.cocoon</groupId>
       <artifactId>cocoon-spring-configurator</artifactId>
       <version>1.0.0</version>
     </dependency>

And [2]:

     <dependency>
       <groupId>org.apache.cocoon</groupId>
       <artifactId>cocoon-configuration-api</artifactId>
       <version>1.0.0</version>
     </dependency>

And there is one more. When trying to build Cocoon [3], this causes 'artifact 
not found' errors. And as soon as I remove these lines, everything becomes 
peachy. Any reason to keep these lines? If yes, why versions are hardcoded only 
in these three places?

Vadim


[1] 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-sitemap/cocoon-sitemap-impl/pom.xml
[2] 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-store/cocoon-store-impl/pom.xml
[3] rm -rf ~/.m2/repository/org/apache/cocoon; mvn -o install

Re: pom poms

[Daniel Fagerstrom <da...@nada.kth.se>]

Carsten Ziegeler skrev:
> Vadim Gritsenko wrote:
>> Carsten Ziegeler wrote:
>>> Vadim Gritsenko wrote:
>>>> I don't think it is, in this case. There is a new element -
>>>> configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot
>>>> must be used.
>>> Ah, ok - sure, then lets release 1.0.1 :)
>> So what are you waiting for?! :)
>>
> To be honest, I have no idea how we do the release in 2.2 right now. If
> someone gives me some hints, I'll do it.

http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g4/g1/1199.html

/Daniel

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Grzegorz Kossakowski wrote:
> It's like being disappointed that it's hard to build all our external 
> dependencies like Spring, commons, etc. and ask for one magic command.

See: gump ;-)

Vadim

Re: pom poms

[Grzegorz Kossakowski <gk...@apache.org>]

Vadim Gritsenko pisze:
> Grzegorz Kossakowski wrote:
>> Vadim Gritsenko pisze:
>>
>>
>> What's the use of building released artifacts if they are on public 
>> mirrors ready for download?
> 
> I'm paranoid! :-O

LOL ;-)
If it helps your aberrations, all binaries are signed! :-P

> PS It was a one command affair in 2.1 time - does it *have* to be a 
> *huge* pain in the ass with maven and 2.2?

Because C2.1 and C2.2 differ in basis. In 2.1 we had one, monolithic release performed from whole tree of source code. Now, we have 
independent releases cycles and one of consqeuences of such approach is that one Cocoon's artifact can (and usually should, if possible) 
depend on another Cocoon's artifact that is released. That means the released Cocoon's artifact is no way different from external artifacts 
when treated as dependency.

It's like being disappointed that it's hard to build all our external dependencies like Spring, commons, etc. and ask for one magic command.

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> So - as mentioned on the top of email - it is huge pain to assemble such
>> a tree, but it is absolutely possible to do.
>
> Yes, but the tree is not what you might expect - it might be that we
> have a cocoon-core 2.2.2 while we still use cocoon-pipeline-api 2.2.0
> with impl 2.2.7.

Yup, no problem. I'd even expect so down the road.


> And even worse, you might want to decide to use impl
> 2.2.5 as you think that it works better than 2.2.7.

If one decides so, yes.


> So what one could do, is maintain a list of all modules with their
> latest versions, write a three lines script which checks out these
> modules and versions, and you get what you want (at least I think this
> is what you want).

Yes, can I have this magic three line script, please :) Even better, can we have 
it checked in under .../cocoon/tags/ so that *anybody* can get the script, run 
it - and voila! - you get a release of cocoon built :)

Vadim


> Oh, and we might have this list already in the root
> pom in the version depmgmt (although I still think that this is wrong).
> 
> Carsten

Re: pom poms

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote:
>>
>> This has nothing to do with maven
> 
> Is it? :)
> 
No, not this time :)
> 
>> - we now have different release cycles
>> for the various arifacts. It is no longer one single monolithic
>> application you built - it is an assembly of several parts. And all have
>> their own versioning etc.
> 
> Yes but this does *not* make it impossible to assemble a tree which
> would consist of all (even separately) released artifacts which can
> nicely work together and you can still build all of them in one go using
> single command line command.
> 
> Just to illustrate the point, in case above was not clear, it could be:
> 
> tags/
>  \-- cocoon-2.2-rc1/
>       |-- core
>       |    |-- cocoon-core (copied from cocoon-core-2.2-rc1 tag)
>       |    |-- cocoon-pipeline
>       |    |    \-- cocoon-pipeline-api (copied from
> cocoon-pipeline-api-2.2rc1 tag)
> 
> ...
> 
> So - as mentioned on the top of email - it is huge pain to assemble such
> a tree, but it is absolutely possible to do.
> 
Yes, but the tree is not what you might expect - it might be that we
have a cocoon-core 2.2.2 while we still use cocoon-pipeline-api 2.2.0
with impl 2.2.7. And even worse, you might want to decide to use impl
2.2.5 as you think that it works better than 2.2.7.

So what one could do, is maintain a list of all modules with their
latest versions, write a three lines script which checks out these
modules and versions, and you get what you want (at least I think this
is what you want). Oh, and we might have this list already in the root
pom in the version depmgmt (although I still think that this is wrong).

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> PS It was a one command affair in 2.1 time - does it *have* to be a
>> *huge* pain in the ass with maven and 2.2?
>
> This has nothing to do with maven

Is it? :)


> - we now have different release cycles
> for the various arifacts. It is no longer one single monolithic
> application you built - it is an assembly of several parts. And all have
> their own versioning etc.

Yes but this does *not* make it impossible to assemble a tree which would 
consist of all (even separately) released artifacts which can nicely work 
together and you can still build all of them in one go using single command line 
command.

Just to illustrate the point, in case above was not clear, it could be:

tags/
  \-- cocoon-2.2-rc1/
       |-- core
       |    |-- cocoon-core (copied from cocoon-core-2.2-rc1 tag)
       |    |-- cocoon-pipeline
       |    |    \-- cocoon-pipeline-api (copied from cocoon-pipeline-api-2.2rc1 
tag)

...

So - as mentioned on the top of email - it is huge pain to assemble such a tree, 
but it is absolutely possible to do.

Vadim

Re: pom poms

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote:
> Grzegorz Kossakowski wrote:
>> Vadim Gritsenko pisze:
>>
>>> I want to build Cocoon :) Including, let's say,
>>> configurator-api-1.0.0. I don't want it to be downloaded - I want to
>>> build it. :)
>>
>> What's the use of building released artifacts if they are on public
>> mirrors ready for download?
> 
> I'm paranoid! :-O
> 
> 
> PS It was a one command affair in 2.1 time - does it *have* to be a
> *huge* pain in the ass with maven and 2.2?
> 
This has nothing to do with maven - we now have different release cycles
for the various arifacts. It is no longer one single monolithic
application you built - it is an assembly of several parts. And all have
their own versioning etc.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Grzegorz Kossakowski wrote:
> Vadim Gritsenko pisze:
> 
>> I want to build Cocoon :) Including, let's say, 
>> configurator-api-1.0.0. I don't want it to be downloaded - I want to 
>> build it. :)
> 
> What's the use of building released artifacts if they are on public 
> mirrors ready for download?

I'm paranoid! :-O


PS It was a one command affair in 2.1 time - does it *have* to be a *huge* pain 
in the ass with maven and 2.2?

Vadim

Re: pom poms

[Grzegorz Kossakowski <gk...@apache.org>]

Vadim Gritsenko pisze:

> I want to build Cocoon :) Including, let's say, configurator-api-1.0.0. 
> I don't want it to be downloaded - I want to build it. :)

Vadim, I think it only makes sense to build artifacts that have not been released, yet.

What's the use of building released artifacts if they are on public mirrors ready for download?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> I get it... But this comes at a great price of not being able to build
>> Cocoon

    ^^^^^^

>> with sane amount of work. What I would like to avoid is to do
>> something like this manually:
>>
>>  * rm -rf ~/.m2/repository/org/apache/cocoon
>>  * Checkout cocoon-configurator-api tag 1.0.0
>>  * mvn install
>>  * mvn source:jar
>>  * Checkout cocoon-spring-configurator tag 1.0.1
>>  * mvn install
>>  * mvn source:jar
>>  * Checkout cocoon-doohickey-ho tag 1.2.3
> I want that one! Where is it? :)
> 
>>  * mvn install
>>  * mvn source:jar
>>  * (... repeat another 100 times ...)
>>
>> What I would like to do is:
>>
>>  * rm -rf ~/.m2/repository/org/apache/cocoon
>>  * Checkout cocoon tag 2.2-RC1
>>  * mvn install
>>  * mvn source:jar
>>
>> I see how I can do former for all artifacts comprising current RC1
>> release; do you have a suggestion on how to do latter?
> Hmm, sorry I don't get your problem

I want to build Cocoon :) Including, let's say, configurator-api-1.0.0. I don't 
want it to be downloaded - I want to build it. :)

Vadim

> - if a module is refering to a
> released artifact of cocoon, let's say configurator-api 1.0.0, than this
> is in the global repository. Sure if you remove your whole local
> repository, then you ran into problems when building with -o option.
> But why do you want to delete your local repository?
> I would replace the "rm -rf ~/.m2/repository/org/apache/cocoon"
> with a version that only removes snapshot from the mentioned directory.
> That should solve your problem I think.
> 
> Carsten

Re: pom poms

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>> Vadim Gritsenko wrote:
>>> I don't think it is, in this case. There is a new element -
>>> configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot
>>> must be used.
>> Ah, ok - sure, then lets release 1.0.1 :)
> 
> So what are you waiting for?! :)
> 
To be honest, I have no idea how we do the release in 2.2 right now. If
someone gives me some hints, I'll do it.

> I get it... But this comes at a great price of not being able to build
> Cocoon with sane amount of work. What I would like to avoid is to do
> something like this manually:
> 
>  * rm -rf ~/.m2/repository/org/apache/cocoon
>  * Checkout cocoon-configurator-api tag 1.0.0
>  * mvn install
>  * mvn source:jar
>  * Checkout cocoon-spring-configurator tag 1.0.1
>  * mvn install
>  * mvn source:jar
>  * Checkout cocoon-doohickey-ho tag 1.2.3
I want that one! Where is it? :)

>  * mvn install
>  * mvn source:jar
>  * (... repeat another 100 times ...)
> 
> What I would like to do is:
> 
>  * rm -rf ~/.m2/repository/org/apache/cocoon
>  * Checkout cocoon tag 2.2-RC1
>  * mvn install
>  * mvn source:jar
> 
> I see how I can do former for all artifacts comprising current RC1
> release; do you have a suggestion on how to do latter?
Hmm, sorry I don't get your problem - if a module is refering to a
released artifact of cocoon, let's say configurator-api 1.0.0, than this
is in the global repository. Sure if you remove your whole local
repository, then you ran into problems when building with -o option.
But why do you want to delete your local repository?
I would replace the "rm -rf ~/.m2/repository/org/apache/cocoon"
with a version that only removes snapshot from the mentioned directory.
That should solve your problem I think.

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> I don't think it is, in this case. There is a new element -
>> configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot
>> must be used.
> Ah, ok - sure, then lets release 1.0.1 :)

So what are you waiting for?! :)


>>> As the
>>> configuration stuff is nearly the only stuff which has a final release,
>>> it just there that we use the version. Now, why it fails, I don't know
>>> as these artifacts should be in public repositories.
>> (see -o flag, forces complete local build)
>>
> Hmm, in this case it's a dependency like one to any other third party
> lib - if you build with -o and don't have it in your local repo the
> build will fail. If you don't have the spring jar in your local repo it
> will fail as well. I don't see any difference here.
> 
> Believe me, we have to remove the snapshot dependencies as soon as
> possible. It's a mess right now. (Of course without releasing we can't
> change this)

I get it... But this comes at a great price of not being able to build Cocoon 
with sane amount of work. What I would like to avoid is to do something like 
this manually:

  * rm -rf ~/.m2/repository/org/apache/cocoon
  * Checkout cocoon-configurator-api tag 1.0.0
  * mvn install
  * mvn source:jar
  * Checkout cocoon-spring-configurator tag 1.0.1
  * mvn install
  * mvn source:jar
  * Checkout cocoon-doohickey-ho tag 1.2.3
  * mvn install
  * mvn source:jar
  * (... repeat another 100 times ...)

What I would like to do is:

  * rm -rf ~/.m2/repository/org/apache/cocoon
  * Checkout cocoon tag 2.2-RC1
  * mvn install
  * mvn source:jar

I see how I can do former for all artifacts comprising current RC1 release; do 
you have a suggestion on how to do latter?


Vadim

Re: pom poms

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote:
> I don't think it is, in this case. There is a new element -
> configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot
> must be used.
Ah, ok - sure, then lets release 1.0.1 :)

> 
> 
>> As the
>> configuration stuff is nearly the only stuff which has a final release,
>> it just there that we use the version. Now, why it fails, I don't know
>> as these artifacts should be in public repositories.
> 
> (see -o flag, forces complete local build)
> 
Hmm, in this case it's a dependency like one to any other third party
lib - if you build with -o and don't have it in your local repo the
build will fail. If you don't have the spring jar in your local repo it
will fail as well. I don't see any difference here.

Believe me, we have to remove the snapshot dependencies as soon as
possible. It's a mess right now. (Of course without releasing we can't
change this)

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: pom poms

[Vadim Gritsenko <va...@reverycodes.com>]

Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> Got a question about poms... Is there any reason why versions of some
>> artifacts are hardcoded in some of the poms? Specific examples are [1]:
>>
>>     <dependency>
>>       <groupId>org.apache.cocoon</groupId>
>>       <artifactId>cocoon-spring-configurator</artifactId>
>>       <version>1.0.0</version>
>>     </dependency>
>>
>> And [2]:
>>
>>     <dependency>
>>       <groupId>org.apache.cocoon</groupId>
>>       <artifactId>cocoon-configuration-api</artifactId>
>>       <version>1.0.0</version>
>>     </dependency>
>>
>> And there is one more. When trying to build Cocoon [3], this causes
>> 'artifact not found' errors. And as soon as I remove these lines,
>> everything becomes peachy. Any reason to keep these lines? If yes, why
>> versions are hardcoded only in these three places?
>>
> We should depend on released stuff whereever possible.

I don't think it is, in this case. There is a new element - 
configurator:bean-map - which is not part of 1.0 - so 1.0.1 snapshot must be used.


> As the
> configuration stuff is nearly the only stuff which has a final release,
> it just there that we use the version. Now, why it fails, I don't know
> as these artifacts should be in public repositories.

(see -o flag, forces complete local build)

Vadim

> Using the mvn dep mgmt for dependencies that come out of the same
> project is imho bad and doesn't work as soon as every module has
> separate release cycles. So while it is general useful to have all third
> party versions in the root pom, it doesn't work for artifacts of the
> same project. So this is the reason why they are hard-coded in some poms.
> 
> HTH
> Carsten

Re: pom poms

[Carsten Ziegeler <cz...@apache.org>]

Vadim Gritsenko wrote:
> Hi All,
> 
> Got a question about poms... Is there any reason why versions of some
> artifacts are hardcoded in some of the poms? Specific examples are [1]:
> 
>     <dependency>
>       <groupId>org.apache.cocoon</groupId>
>       <artifactId>cocoon-spring-configurator</artifactId>
>       <version>1.0.0</version>
>     </dependency>
> 
> And [2]:
> 
>     <dependency>
>       <groupId>org.apache.cocoon</groupId>
>       <artifactId>cocoon-configuration-api</artifactId>
>       <version>1.0.0</version>
>     </dependency>
> 
> And there is one more. When trying to build Cocoon [3], this causes
> 'artifact not found' errors. And as soon as I remove these lines,
> everything becomes peachy. Any reason to keep these lines? If yes, why
> versions are hardcoded only in these three places?
> 
We should depend on released stuff whereever possible. As the
configuration stuff is nearly the only stuff which has a final release,
it just there that we use the version. Now, why it fails, I don't know
as these artifacts should be in public repositories.

Using the mvn dep mgmt for dependencies that come out of the same
project is imho bad and doesn't work as soon as every module has
separate release cycles. So while it is general useful to have all third
party versions in the root pom, it doesn't work for artifacts of the
same project. So this is the reason why they are hard-coded in some poms.

HTH
Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org