Chris Berry wrote:
Kenney,
It's not about taste. Defining repos in teh POM are a real problem.
Here's an example; I recently got a POM from someone that had the
SNAPSHOT repo defined in the POM. Fine, as long as you could get at
it, which we couldn't. But that aside, this repo element defined
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
So now let's assume I'm a build engineer that will *never* allow
SNAPSHOTs. So what are they to do -- edit the POM to remove this
statement. That seems very wrong to me. These guys don't edit POMs --
they build things. (i.e. check out on v1.1.2 tag, build it, and deploy
the artifacts) And if they then check this altered POM back into the
SCM, (which they should for repeatability and proper tagging) what
happens to teh develoer that needs to use SNAPSHOTs. They would have
to change it back. And on and on... Does that seem right?? What am I
missing??
In my opinion, repo info is orthogonal to the project definition,
Coupling them seems a mistake, particularly juxtaposed against large
organizations with tight change control and production build policies.
Cheers,
-- Chris
Chris,
We haven't stepped up to actually using m2 on project, still m1, but
I've been exploring it's capabilities and the code base. This is
definitely an interesting topic for helpling to understand m2 issues and
prepare for transition.
I tend to agree with you regarding the repo info, but couldn't the same
argument be made of other POM info such as SCM URLs? Such info certainly
doesn't make sense outside of most organizations (does/could m2 filter
out such POM info when deploying to an external repo????).
Perhaps the best practice depends on the audience for the POM:
1.) If the POM will never "leave the house", I think Kenny is right.
2.) If the artifact is to be publicly published, you're on track and
either the best practice changes, or some culling of the POM info needs
to (automagically?) happen.
3.) If the POM is delivered as part of a source distribution, then I
think we're back to #1
What is the context of your example where you "received a POM from a
friend"? Was it 1,2,3 above, or something I've missed?
BTW, I hope your build engineer does more than checkout, build and
deploy otherwise their job is in jeopardy ;) Since you mention they
"will *never* allow SNAPSHOTs", is that then part of their job -- they
resolve SNAPSHOT dependencies? In which case they may very well require
checking the POM back into SCM.
DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
