.
Stephen Connolly wrote:
No.
e.g.
(I own one-dash.com)
I might roll a custom version of log4j...
I would deploy this as
groupId=com.one-dash
artifactId=log4j
version=1.2.14
Why should I have to change the package names?
2009/3/20 Merv Green paradeofh...@gmail.com
Is it reasonable
Is it reasonable to insist that a project's Java package name matches
${project.groupId}.${project.artifactId}, with dashes converted to
underscores, etc?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For
M2eclipse lists everything from the catalog, but cannot generate the
corresponding projects unless the Nexus indexer also finds the
archetypes. Manually updating the local index from Eclipse's 'Nexus
Indexes view' lets m2e use them.
This comes with the inconvenience that m2e fails to release
This post,
http://www.sonatype.com/people/2008/05/misused-maven-terms-defined/ ,
points out that, like the Highlander, there can be only one Super pom.
But corporate pom and organizational pom are just too hard to say.
Choosing an extensible name seems handy; you could declare, for
instance,
The only way I know is to configure your repository manager. For
example, see the Nexus FAQ,
https://docs.sonatype.com/display/NX/Nexus+FAQ
houzecl wrote:
Hi all,
Maven allows us to release artifacts properly with the release plugin.
However, nothing prevents to use the deploy plugin
Apologies if I was a bit brusque. Though I can't think of any reason
why, I was speculating that it might involve something insidious about
how the compiler or surefire expects the project structure. Different
directory names help isolate the problem.
Anyhow, you might have an old version of
You may be abusing 'src' and 'test.' Do you get the same problem if you
rename the sub-projects 'dir1' and 'dir2?' Have you considered something
like the shitty-maven-plugin? Google for 'maven integration testing.'
klimane wrote:
I have the following project structure:
ProjectA
pom.xml
Simply enough,
...
plugin
artifactIdmaven-site-plugin/artifactId
configuration
siteDirectorysite/siteDirectory
/configuration
/plugin
...
I doubt, however, that this is really what you're looking for. At risk
Chris Helck wrote:
Could you clarify the security requirement? It sounds like you don't want
unverified jars entering the development space. Is this correct?
That is essentially correct.
-
To unsubscribe, e-mail:
experimenting with Nexus for a little
while now. Good work.
In short, two handy URLs:
http://books.sonatype.com/nexus-book/reference/procure.html
http://blogs.sonatype.com/people/2009/01/nexus-professional-what-is-procurement/
Hope helps,
~t~
On Sat, Jan 31, 2009 at 9:36 PM, Merv Green paradeofh
Message-
From: Merv Green [mailto:paradeofh...@gmail.com]
Sent: Sunday, February 01, 2009 2:14 PM
To: Maven Users List
Subject: Re: Maven for the internet afraid
I need to clarify my question.
The security people at my company certainly want the finest-grained
control possible over artifacts
So, in my quest to take Maven completely internal, I'm still grappling
with a couple of use cases:
1. Gathering plugin dependencies
We have some list of approved plugins we somehow decide we need. For
each, we want to populate our repo with any artifacts those plugins
might require in use.
Asking this embarrasses me, but must be done.
I work for a company where the internet terrifies Them. They want to use
Maven, but they think it should never go online, so they want a locked
down internal repository containing whatever artifacts some couple
hundred developers might need.
Can
13 matches
Mail list logo
