Pom? in the singular? Checkin of pom breaks another develper?
I have a team of 9 developers, we have over 113 artifacts... i.e. poms with
independent versions. we must have over 4000 tags with another 20 live
branches (i.e. 20 other version of some of those artifacts)
10 or so of those are aggregations i.e. jars, wars that are deployed into dev,
staging, uat and production environments.
the definition of each artifact is its poms... some of the aggregating poms
are too complex but that only because people didn't take the time to
understand the code they are trying to write and deploy...
you should not be thinking of poms in the singular, just like you would not
write one giant class but refactor it into smaller units dealing with each
particular aspect of the system, you should do the same thing with artifacts
It only takes one person to really learn maven2 to produce a system that
functions well at this level of complexity... but then I would argue that the
system is by its nature complex... maven2 just lets us formally define
exactly what the system is at all levels...
IOC and DI
-----------------
all of our code is based around DI and IOC we make heavy use of spring...
if you work hard you can have clearly defined efferent and afferent couplings
between not just classes but artifacts, this will give you the most and
stablest reuse of all the code you produce.
one significant advantage is the ability to branch at all levels and to
rapidly alter the structure of any assembly/aggregate
Source vs Binary dependency
-------------------------------------------
One of the crappest things ever is having another developer on your team waste
hours of your time because they checked in some code that was not correct.
Maven solves this problem very elegantly... with the concept of an artifact
release.... DONT depend on trunk but depend on the last release in a version
range... e.g.
Source dependency can be equated directly with snapshots and the head of any
trunk or branch
Binary depedencies relate to a dependency to a tag of a trunk or branch.
Now obviously it is desirable for a developer to integrate often thereby
commit code changes but at the same time not breaking other developers.
If you only ever binary deps then as the developer of one artifact you can
choose when you upgrade the efferent coupling and as such waste the least
amount of time.
You may also choose at what stage your artifact is most suitable for release
to other developers... so many commits result in a release...
By definition - unless you are doing something dodgy - each release will mean
that all the the tests pass! So you are far less likely to be wasting your
peers time... as a bonus if you do screw things up you can roll back to the
last tag
rpm, urpmi, yum, portage, deb, oh and the poor cousin dpkg
-----------------------------------
if you don't already know linux i would highly recommend that you read up on
package managers and what they try to achieve and how they do it.... the most
common problem I find is that because Windows(tm) has no proper package
management people never get, it by that i mean understand the power and
simplicity of actually managing the software that is deployed on a system...
On Tuesday 23 October 2007 20:13, baumar wrote:
> Thanks Michael for the mental aid and please be leniant to my slow
> reception. I am working in the area of OO programmer since 91 (and used ant
> as few as possible because of the reason you hint at), I read a lot of use
> and abuse and it seems to me the term OO is often a bit dilapidated, isn't
> it.
>
> Shouldn't we more often think of solving practical problems instead of
> getting stuck with fighting for technological concepts an supremacy? A good
> example for this seems to me the pattern oriented approach trying to build
> a layer in top of technical solutions. In this case I'm thinking about a
> pattern called "Dependency injection" also known as "Inversion of control";
> this title describes better what we would like to do.
>
> We are a team of 6 people working - what a surprise - under heavy load.
> Everybody needs to be able to run a build as easy as possible, that's why
> we wanted to try Maven. But not everybody has time to study Maven
> thoroughly; our pom has become a bit bigger and complex, it is under
> version control, thus an error or just a typo would affect the whole team.
> If unfamiliar people start to fumble in the pom, which IMU is essentially
> the heart of the build process, this seems (a bit exagerated, ok) like a
> nurse taking over during a heart surgery while the doctor goes for a
> coffee. However, the team decided to keep the version number as simple as
> possible and therefore would like to have it in a clearly dedicated file to
> focus on only that action (isn't separation of concerns a highly praised
> paradigm of maven?)
> I see that reading in values into the pom adds a new layer of complexity
> and you may you should not multiply things to much. However, it seems to be
> practical to separate basic setup parameters into something like a
> configuration file.
>
> Eventually, we would also have the version number being generated by an
> algorithm in the versioning system. Of course we could use an ant task to
> write that version into the pom file, but I understood that's what you
> wanted to bring us away from. How else is an automated build process
> stuffing the build number into the maven process? Isn't it the most simple
> and robuste way to write it into a - separate - file?
>
> I hope I made our point clear that there might good arguments to allow
> values being feeded into the pom from an external source and maybe give
> some motivation to make the pom file a bit "semipermeable"
>
> Thanks for the discussion
>
> Markus
>
> Michael McCallum-3 wrote:
> > there is no right way to read the version from a file.. the pom is the
> > file
> > that contains the version...
> >
> > stop thinking like an ant script and start thinking like an OO programmer
> >
> > BTW thats not meant to be critical or offensive just to catch your
> > attention
> > and make you think...
> >
> > On Tuesday 23 October 2007 03:47, baumar wrote:
> > t> Hi,
> >
> >> What would be the right way to read the version number from a file?
> >>
> >> We decided that not all users (who maybe don't know maven very well)
> >> should
> >> check out the delicate pom file .
> >> We have a file like version.properties containing
> >>
> >> tavx.current.version=1.2.3a
> >>
> >> and defined in the pom
> >>
> >> <project>
> >> <modelVersion>4.0.0</modelVersion>
> >> <groupId>com.abc.tat.tavx</groupId>
> >> <artifactId>tavx</artifactId>
> >> <name>adapter</name>
> >> <packaging>jar</packaging>
> >> <version>${tavx.current.version}</version>
> >> ...
> >> <build>
> >> <filters>
> >> <filter>src/resources/version/version.properties</filter>
> >> </filters>
> >>
> >> but that doesn't work.
> >>
> >>
> >> Thanks for help
> >>
> >> Markus
> >
> > --
> > Michael McCallum
> > Enterprise Engineer
> > mailto:[EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
Michael McCallum
Enterprise Engineer
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
