On 5/12/10 5:52 PM, Chris Blunck wrote:
> On Wed, May 12, 2010 at 4:25 PM, Guillaume Nodet <[email protected]> wrote:
>
>> On Wed, May 12, 2010 at 13:51, Chris Blunck <[email protected]> wrote:
>>
>>> On Wed, May 12, 2010 at 2:30 PM, Justin Edelson <[email protected]
>>>> wrote:
>>>
>>>> On 5/12/10 2:19 PM, Chris Blunck wrote:
>>>>> On Wed, May 12, 2010 at 1:48 PM, Justin Edelson <
>>> [email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Maybe I'm too far into the "Maven community", but I don't see a
>>>> problem
>>>>> here. You say:
>>>>>
>>>>> > The problem I have arises when app1 and app2 use different
>>>>> versions of the
>>>>> > commons module. If app1 references commons/1.0.0 as a
>> dependency
>>>>> and app2
>>>>> > references commons/2.0.0 as a dependency I'm in trouble because
>>> my
>>>> top
>>>>> level
>>>>> > pom.xml can't build both versions of commons in the same
>> reactor.
>>>>>
>>>>> But nothing in Maven prevents you from depending upon different
>>>> versions
>>>>> of the same artifact from different projects in a reactor build.
>>>> While
>>>>> it is true that you can only have one version of commons in the
>>>> reactor
>>>>> at a time, this doesn't have anything to do with using commons as
>> a
>>>>> dependency. Within the same reactor, you can have:
>>>>>
>>>>> app1 -> commons 1.0
>>>>> app2 -> commons 2.0
>>>>> commons (could be version 1.0, version 2.0 or anything else)
>>>>>
>>>>>
>>>>> You are correct that this is handled gracefully within Maven.
>> However,
>>>>> it presupposes that both commons-1.0 and commons-2.0 have been
>>>>> previously built and installed into a maven repository that is
>>>>> accessible to app1 and app2.
>>>>>
>>>>> What should be done if that assumption is not valid?
>>>> Make it so... Maven isn't really usable without artifacts in
>>> repositories.
>>>>
>>>
>>> I agree. I think the question is: how do you populate the repository?
>>>
>>
>> When you decide to release a component, you should use the maven release
>> plugin that will do all the work for you (creating the svn tag and
>> uploading
>> the release in the repository).
>> That way, your repository will be populated over time with all the versions
>> that will be released. That's how all maven repositories work.
>> In addition to your own repository containing your releases, you'll need a
>> repository containing external libraries (pointing either to central or
>> your
>> own controlled repository containing approved libraries).
>>
>
> Yes. That all makes sense and is very logical. However ... it puts the
> "building" of the components that go into a release into the hands of the
> developers. I'm ok with that but not all development environments are
> comfortable with that approach. Some development shops have separate "CM"
> teams who's entire job is to checkout, build, and release. In those
> environments we still haven't tackled the underlying problem of building
> multiple versions of the "commons" module.
Nothing above requires that the "developers" be the ones doing the
releasing.
>
>
>
>>>> In other words ... a new developer svn co's the codebase and wants to
>> do
>>>>> a full-build so they can deploy the app. If the artifacts for
>>>>> commons-1.0 and commons-2.0 are not in a maven repository then how
>> does
>>>>> that new developer build them? Since they are artifacts of the
>> project
>>>>> it seems logical (to me) that a new developer on the project should
>> be
>>>>> able to build them without much hassle.
>>>> A) the release artifacts should be in a Maven repository.
>>>> B) developers shouldn't be building releases
>>>> C) If a developer needs to build a module, they should check it out of
>>>> version control and build it.
>>>>
>>>
>>> I agree with all those statements. What I'm searching for is the handoff
>>> between A and B. Developers shouldn't build releases but they do play a
>>> role in the process in that developers possess the knowledge of what
>>> ingredients should be blended together to create a release. Maven has
>> been
>>> very effective as an expression of that recipe (e.g. my app depends on
>>> these
>>> other modules and this is how they all go together).
>>>
>>> I think we're somewhat in agreement here.
>>>
>>> If developers "shouldn't be building releases" as you point out then that
>>> suggests that the release engineers need to build the software that will
>> be
>>> released. Ideally they would use the same recipes the developers used:
>> the
>>> various pom.xml files.
>>>
>>> Once a release has been cut, the artifacts will have been deployed into
>> the
>> repository as part of the release process. So developers should not
>> checkout a tag and build it themselves, they should rely on repositories to
>> grab all their dependencies.
>>
>
> Agreed. I'm thinking of the CM teams though that want to deploy an OSGi
> based application. If they can't peer into the developer repository and
> they need to build multiple versions of the "commons" module how would they
> do so?
Where is the restriction coming from that the CM team can't peer into
the "developer repository"? In any case, if you follow the best practice
that releases only depend upon other releases, this isn't an issue
anyway. The CM team only has to deal with the "release" repository
because all of the dependencies they need have already been released.
>
>
>
>>
>>>>> You seem to be wanting to have the entire transitive closure
>>> defined
>>>> in
>>>>> a single build, which is just unnecessary and seems at odds with
>>> the
>>>>> idea of doing modular development.
>>>>>
>>>>>
>>>>> Perhaps you can steer me in another direction after considering what
>>>>> I've described above?
>>>>>
>>>> Mostly it seems to me you're trying to avoid having a repository. I
>>>> would steer you away from this. If you are doing non-trivial
>> development
>>>> with Maven (or, arguably, with anything), you need an artifact
>>> repository.
>>>>
>>>
>>> Not quite... I very much want a repository chock full of multiple
>> versions
>>> of artifacts. But I also want to be able to build that repository up
>> from
>>> scratch (when I'm building from within a .spec file) so that I can
>>> distribute it as an RPM.
>>>
>>>
>> You may want to have a look at the features-maven-plugin from karaf which
>> is
>> used to create the repository from a karaf features.
>> That's what we actaully use to build the karaf distribution. It won't
>> package it for you, but it will grab the dependencies and move them into a
>> fodler that you can zip later.
>>
>>
> Thanks for the tip - I checked out the features-maven-plugin and it looks
> very cool. From what I gather features-maven-plugin looks at a features
> file and then copies all the referenced bundles and places them in a
> particular output directory. The referenced bundles are presumably resolved
> via pax-url and in the case of mvn: referenced bundles they are downloaded
> either from ~/.m2/repository or some remote nexus. That looks really really
> useful but it presupposes that the artifacts already exist in
> ~/.m2/repository or in a remote nexus.
>
> My problem space lies 1 layer up: how do I get multiple versions of the
> bundles into my repository.
You release them individually.
>
> I wish I saw a clear-cut and easy way to achieve that but nothing is coming
> to mind.
>
> On one mind you could brute force it with "find . -name pom.xml -exec "cd
> '{}' && mvn install" but that's overly simplistic and doesn't handle
> intra-project dependencies.
>
> A more elegant solution would be to use maven-dependency-plugin on each
> pom.xml and then gracefully go and "mvn install" for each intra-project
> dependency. But the problem with that approach is: how can you
> differentiate between intra-project dependencies and third party (OSS)
> dependencies. I suppose you could try to cd around to directories based on
> groupId/artifactId/version and if it fails then assume the dependency is OSS
> and punt. Seems kinda skanky though...
>
> Anyway... Thanks for all your ideas and opinions. Maybe this will spawn
> some more conversation on how to best approach the provisioning and
> distribution problem faced by developers and release managers.
>
>
> -c
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
