On 11/12/2010 3:15 PM, Brian Topping wrote:
On Dec 11, 2010, at 3:59 AM, Stephen Connolly wrote:
My issue with using orofiles for adding modules is that you can end up with
version numbers out of sync.... of course that's why I created
versions-maven-plugin, but that is just a band-aid.
Is this because the release plugin doesn't see some modules when doing a
release on a module subset or am I missing something else?
Initially, I didn't imagine someone doing a release on a profile that contained
less than a full set of modules, but see the error in that logic now (it would
appear to be a very clean way to release a subset of functionality), and as I
put this together with the functionality in the versions-maven-plugin, can
better imagine the kinds of builds you are working with.
Using profiles to pull in modules can just as easily result in broken
builds... what I ended up doing is using profiles to turn off the system
specific parts of a build when on a system without those system specific
components (e.g. missing flashplayer, rpmbuild), but also to fail a release
if the system specific components are missing.
So are you also of the camp that having multiple "developer POMs" is the best
practical solution?
It seems like these approaches are essential for projects that have grown to the size of the death
star, and what I am asking myself now is whether there is a breakeven to starting a project with
the "wrong" patterns (saving time during early agile development due to things like IDE
integration) versus avoiding profiles wherever possible from the start and skipping the pit stop to
migrate everything down the road. In other words, are these "good problems to have" (the
company and it's IP got out of the incubator and now this as a problem) versus solving them too
early being counterproductive to getting smaller projects off the ground.
This is a very constructive way to look at the problem.
Having gone through this process, we wish that we had done it better
from the start but we never got mixed up in profiles. Our main lessons
learned are:
1) get your repo up early.
2) RTFM and RTFB
3) move to SOA as early as you can. MVC is great and MV-SOA is better.
Look at every process that you build to see if it can be better designed
as a service using other services.
4) break the project into libraries. They are likely to be more stable
and easier to change. We are still looking for opportunities to extract
out common functions that are shared
5) stay away from exotic or custom plug-ins and profiles until you get
the basics working. Optimization at the start is bound to be hard and
likely to lock you into bad practices before you know what you are doing.
Ron
Thanks, Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
