Sat, 5 Jan 2013 23:52:50 +0100, /Anders Hammar/:
I always argue for having the API (e.g. ejb client) as a separate module
and then the impl (e.g. the ejb) as a separate module.
That's what we're using after all, but I've recently discovered this
ejb-client option and started wondering if ther
Totally agree ++
On Sat, January 5, 2013 2:52 pm, Anders Hammar wrote:
> I always argue for having the API (e.g. ejb client) as a separate module
> and then the impl (e.g. the ejb) as a separate module.
>
> /Anders
>
>
> On Sat, Jan 5, 2013 at 11:45 PM, Manfred Moser
> wrote:
>
>> On Sat, January
I always argue for having the API (e.g. ejb client) as a separate module
and then the impl (e.g. the ejb) as a separate module.
/Anders
On Sat, Jan 5, 2013 at 11:45 PM, Manfred Moser wrote:
> On Sat, January 5, 2013 2:43 pm, Stanimir Stamenkov wrote:
> > Sat, 5 Jan 2013 14:38:38 -0800, /Manfre
On Sat, January 5, 2013 2:43 pm, Stanimir Stamenkov wrote:
> Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/:
>
>> If the dependencies are not applicable for this artifact (e.g. the pom
>> is
>> not valid for it because it is generated against Maven convention) then
>> it
>> should not be an artifa
Sat, 5 Jan 2013 14:38:38 -0800, /Manfred Moser/:
If the dependencies are not applicable for this artifact (e.g. the pom is
not valid for it because it is generated against Maven convention) then it
should not be an artifact in the same coordinates but rather be a
different module with different
If the dependencies are not applicable for this artifact (e.g. the pom is
not valid for it because it is generated against Maven convention) then it
should not be an artifact in the same coordinates but rather be a
different module with different GAV coordinates
On Sat, January 5, 2013 2:34 pm, St
Is it true attached artifacts, that is artifacts with a non-empty
classifier, "inherit" their dependencies from the main artifact?
Stated otherwise - is it possible to specify different set of
dependencies for an attached artifact such that when included in
another project, that different set o
the trick for such scenarios is easy: don't use the release-plugin.
Am Samstag, den 05.01.2013, 13:29 +0100 schrieb Sundeep Reddy
:
Hi All,
The maven release:prepare does the following things:
release: prepare – Performs a number of operations
- Checks to make sure that there are no unc
Does the versions-maven-plugin happen to have a goal for you here?
On Sat, Jan 5, 2013 at 12:01 PM, Robert Scholte wrote:
> Hi,
>
> Since version 2.4 the developmentVersion MUST be a SNAPSHOT, so that trick
> will fail nowadays.
>
> I don't see any reason why to skip these last steps.
> IMHO: in
Hi,
Since version 2.4 the developmentVersion MUST be a SNAPSHOT, so that trick
will fail nowadays.
I don't see any reason why to skip these last steps.
IMHO: in the tag the version must always be a non-SNAPSHOT, in both trunk
and branches the version should always be a SNAPSHOT (expect in t
Hi Sundeep,
I doubt you can skip the last 2 steps, but you could configure the plugin to
"change" the development version to exactly the same version as the release
version. Haven't tried this though:
mvn release:prepare -DreleaseVersion={release-version}
-DdevelopmentVersion={release-version}
Hello Ron,
very valid and good point, thank you. I will describe my scenario:
I have a pipeline of processing steps. Each step is performed by a component
which is packaged into a maven artifact. As the components have been developed
independently of each other, some of them share some dependenc
> Is there way where we could skip the last 2 steps i,e increment of the
> version number and appending the SNAPSHOT . In a way just want to convert
> the snapshot to a release,no further development version.
I am unaware of any such configuration of the plugin which would
permit this. But you cou
Hi All,
The maven release:prepare does the following things:
release: prepare – Performs a number of operations
- Checks to make sure that there are no uncommitted changes.
- Ensures that there are no SNAPSHOT dependencies in the POM file,
- Changes the version of the application and re
14 matches
Mail list logo
