Hi Hervé,
On 4/12/15 3:05 AM, Hervé BOUTEMY wrote:
if you want a release that still targets Maven 2.2.1, yes, we have no choice:
requires to copy plugin versions in reporting section
Given the current status [1] where only maven-eclipse-plugin still requires
its last Maven 2.2.1 release (maven-
It is available on Central .. here is the URL to the main groupId
http://repo1.maven.org/maven2/org/apache/ignite/
And here the core
http://repo1.maven.org/maven2/org/apache/ignite/ignite-core/1.0.0/
The search site takes a bit longer to be up to date after a push but if you
know the coordina
I've been giving this subject lots of thought in some of spare time. IMO,
the most straightforward way of meeting the requirement of the MVJAR is to
break up one's JAR project into separate modules. One module would contain
the version independent code, and then other modules would be per Java
vers
if you want a release that still targets Maven 2.2.1, yes, we have no choice:
requires to copy plugin versions in reporting section
Given the current status [1] where only maven-eclipse-plugin still requires
its last Maven 2.2.1 release (maven-verifier-plugin being in progress), I'm
surprised w
Hello Maven community!
I have noticed today that Apache Ignite 1.0.0 release did not get pushed to
the Maven Central repo.
The latest release is 1.0.0:
http://mvnrepository.com/artifact/org.apache.ignite
However, on maven central, the latest release is 1.0.0-RC3:
http://search.maven.org/#search%
Hi Hervé,
On 4/11/15 7:48 PM, Hervé BOUTEMY wrote:
now that we are not targetting Maven 2.2.1 any more, we could avoid setting
version on reports: version is taken from pluginManagement
Yes i know but this POM is targeting Maven 2.2.1 and not yet 3.X only...
I assume we will an other release
now that we are not targetting Maven 2.2.1 any more, we could avoid setting
version on reports: version is taken from pluginManagement
the only little problem is that Maven 3.0 emits a warning that is a false
positive: I think we can deal with it, isn't it?
Regards,
Hervé
Le samedi 11 avril 2
Hi to all,
i would like to know if some of the dev has some issues/requirements to
be done for a new release of those pom's...
I would like start a release next week if there exist no objections
about this...
Kind regards
Karl Heinz Marbaise
On Saturday, April 11, 2015, Hervé BOUTEMY wrote:
> Le samedi 11 avril 2015 12:31:03 Stephen Connolly a écrit :
> > I think a `finalizeGoals`, defaulting to `initialize` would suffice to
> give
> perhaps an "autoFinalize" boolean too, by default true, for people
> requiring
> the simple current 2
Le samedi 11 avril 2015 15:24:59 Kristian Rosenvold a écrit :
> If committers cannot "manage versions" with option 1, I think we
> should do option 2, since it would make the release process
> increasingly complex for committers and increase the number of
> interactions required.
you need to manag
Le samedi 11 avril 2015 15:35:02 Kristian Rosenvold a écrit :
> Technically we support "main" scoped sources in java6 and "test"
> scoped sources in java7 today, but the feature is largely unusable
> since IDE support is totally missing. Even IntelliJ does not support
> it (https://youtrack.jetbrai
if I read correctly the dicussion on JEP 238 list, there was already someone
who had such idea on more generic "multi-profile" JAR files, jdk being just one
type of profile [1]
but that seems really complex
for Maven, we have the classloader as Classworlds, then we could do what we
want at thi
Technically we support "main" scoped sources in java6 and "test"
scoped sources in java7 today, but the feature is largely unusable
since IDE support is totally missing. Even IntelliJ does not support
it (https://youtrack.jetbrains.com/issue/IDEA-85478 and other issues)
:(
There might be some hope
If committers cannot "manage versions" with option 1, I think we
should do option 2, since it would make the release process
increasingly complex for committers and increase the number of
interactions required.
Kristian
2015-04-11 15:10 GMT+02:00 Karl Heinz Marbaise :
> Hi,
>
> On 4/11/15 2:26 P
Le samedi 11 avril 2015 10:54:34 Kristian Rosenvold a écrit :
> IDE support for multiple source trees seems quite far off ?
IDE support for current situation, where we mix multiple Java API versions in
one single source tree, is even more far off!
With separate source trees, IDE support starts li
Hi,
On 4/11/15 2:26 PM, Hervé BOUTEMY wrote:
ok, thanks for the feedback: we're in the right direction
I'll immediately change the configuration to every Jira project, since the
current SUREFIRE configuration lets committers work on daily basis, which is
important!
then I just had a look at Ji
Le samedi 11 avril 2015 12:31:03 Stephen Connolly a écrit :
> I think a `finalizeGoals`, defaulting to `initialize` would suffice to give
perhaps an "autoFinalize" boolean too, by default true, for people requiring
the simple current 2-phase release process
> people enough of a hook. You could th
On Saturday, April 11, 2015, Hervé BOUTEMY wrote:
> ok, thanks for the feedback: we're in the right direction
> I'll immediately change the configuration to every Jira project, since the
> current SUREFIRE configuration lets committers work on daily basis, which
> is
> important!
>
>
> then I jus
Le samedi 11 avril 2015 12:09:03 Andreas Gudian a écrit :
> Btw, I think that the work that you, Infra and Codehaus have put in for
> this is remarkable - a big thanks from me as well!
notice: this is nice to read :)
-
To unsubsc
ok, thanks for the feedback: we're in the right direction
I'll immediately change the configuration to every Jira project, since the
current SUREFIRE configuration lets committers work on daily basis, which is
important!
then I just had a look at Jira documentation [1]
and it seems managing ve
I think a `finalizeGoals`, defaulting to `initialize` would suffice to give
people enough of a hook. You could then either implement a custom lifecycle
or attach the blue-green toggle actions to a special profile and the push
changes would be part of the default impl of the mojo.
That would give e
A few weeks ago I came up with an additional idea and I'm sure we probably
all recognize this :)
MVJars should also cover dependencies. Several Maven plugins use
reflections to detect if they can use newer methods of of the Maven
Runtime.
In the end this code looks also like
if (isMaven
Hervé, it looks much better now, as far as issues are concerned: I can
assign issues and edit all parts of them (including title and descrition).
That's great :).
But I still can't manage the versions, e.g. add new ones, mark them
released, or add descriptions to them. As that is part of the stuff
I've been thinking of a "finalize" as well, as something which could be
executed if a vote/stage has passed.
But those actions differ between organizations, which would mean either
introduce a lot of hooks or give an API so users can write their own
finalize phases
Op Sat, 11 Apr 2015 09:38
This was part of the discussion we had with Brian,
The need for "some way" to address multi-JDK target environment without
just using the poorest API is a common thing for tools/framework/library
developers. They use to rely on complex profile-based maven builds,
hack-ish ant/gradle scripts, etc a
Stephen,
this does sound even more reasonable. release.properties is deleted at the
end of perform, so the goal could only rely on information in the pom.
Regards
Mirko
--
Sent from my mobile
On Apr 11, 2015 9:40 AM, "Stephen Connolly"
wrote:
> I could see value in a release:finalize goal that
IDE support for multiple source trees seems quite far off ?
Kristian
2015-04-11 8:51 GMT+02:00 Hervé BOUTEMY :
> Hi,
>
> Yesterday at DevoxxFR, Carlos Sanchez, Arnaud Héritier, Nicolas de Loof and me
> met Brian Goetz and discussed about the objective of JEP 238 and what we could
> get from such
I could see value in a release:finalize goal that is a no-op for non-DCVS
but does a push changes for DCVS
It would mean that you could go
mvn release:prepare release:perform release:finalize
in one command to close it all out
On 10 April 2015 at 22:36, Robert Scholte wrote:
> Hmmm, no so sur
28 matches
Mail list logo
