You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Jeff Ramsdale (JIRA)" <ji...@apache.org> on 2009/08/09 09:46:14 UTC
[jira] Created: (RIVER-317) Deploy Apache River artifacts to Maven
repositories (both release and snapshot)
Deploy Apache River artifacts to Maven repositories (both release and snapshot)
-------------------------------------------------------------------------------
Key: RIVER-317
URL: https://issues.apache.org/jira/browse/RIVER-317
Project: River
Issue Type: Task
Components: Web site and infrastructure
Affects Versions: AR2, AR3
Reporter: Jeff Ramsdale
Fix For: AR2
It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: language level?
Posted by James Grahn <jg...@simulexinc.com>.
1.5 was the consensus. If you want 1.6 (due to features, fixes, or
performance), you're free to make the case for it.
Peter Firmstone's tally as we were discussing it:
--------
Those in favour of using Java 6 features:
Jeremy Easton-Marks
Greg Wonderly
James Grahn
Those in favour of using Java 5 features:
Dennis Reedy
Jim Waldo
Jonathan Costers
Greg Trasuk
Niclas Hedhman
Dan Rollo
Greg Wonderly
Jukka Zitting
Sean Landis
Peter Firmstone
James Grahn
Those who would like to see continued support for JRE 1.4 (bytecode
only, using Retrotranslator):
Patrick Wright
Wade Chandler
Peter Firmstone
--------
jamesG
Zsolt Kúti wrote:
> Hello,
>
> I can not find a mail archive search function, that's why this question
> is here: has there been a consensus about what level is targeted with
> development? 1.5 or 1.6?
>
> Thanks
> Zsolt
>
language level?
Posted by Zsolt Kúti <ku...@t-online.hu>.
Hello,
I can not find a mail archive search function, that's why this question
is here: has there been a consensus about what level is targeted with
development? 1.5 or 1.6?
Thanks
Zsolt
Re: [jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by Peter Firmstone <ji...@zeus.net.au>.
Hi Jeff,
Agree to 4: I can't see a problem with adding this patch now, including
it in AR2 then patching it later if need be.
Jeff Ramsdale (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758740#action_12758740 ]
>
> Jeff Ramsdale commented on RIVER-317:
> -------------------------------------
>
> I wouldn't swear they are perfect, but I hope they are a good start. Would love to have them validated by someone. Some questions:
>
> 1) What is the process for applying these poms to the artifacts and rolling them out?
> 2) Can we set up snapshots to deploy too, with CI? (optional, to start)
> 3) Is there anyone who is able to validate these poms before we push?
> 4) Rather than waiting for AR2 can we push the current artifacts now as a test-run for a later AR2 push? That gets the artifacts out there so they can be tested by downstream consumers.
>
>
>> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
>> -------------------------------------------------------------------------------
>>
>> Key: RIVER-317
>> URL: https://issues.apache.org/jira/browse/RIVER-317
>> Project: River
>> Issue Type: Task
>> Components: Web site and infrastructure
>> Affects Versions: AR2, AR3
>> Reporter: Jeff Ramsdale
>> Fix For: AR2
>>
>> Attachments: river-poms.patch
>>
>>
>> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
>> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>
>
>
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Jeff Ramsdale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758740#action_12758740 ]
Jeff Ramsdale commented on RIVER-317:
-------------------------------------
I wouldn't swear they are perfect, but I hope they are a good start. Would love to have them validated by someone. Some questions:
1) What is the process for applying these poms to the artifacts and rolling them out?
2) Can we set up snapshots to deploy too, with CI? (optional, to start)
3) Is there anyone who is able to validate these poms before we push?
4) Rather than waiting for AR2 can we push the current artifacts now as a test-run for a later AR2 push? That gets the artifacts out there so they can be tested by downstream consumers.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Dennis Reedy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761081#action_12761081 ]
Dennis Reedy commented on RIVER-317:
------------------------------------
I'm not sure if you need a new set of poms. For my Rio maven work I needed to add reggie to Rio's maven repository. To day that I simply aded a classifier when deploying the jar:
mvn deploy:deploy-file -Dversion=2.1 -DgeneratePom=true -Dpackaging=jar -DgroupId=com.sun.jini \
-DartifactId=reggie -Dfile=apache-river/lib-dl/reggie-dl.jar -DpomFile=maven2/reggie.pom -DuniqueVersion=false \
-DrepositoryId=rio -Dclassifier=dl -Durl=scp:/...
mvn deploy:deploy-file -Dversion=2.1 -DgeneratePom=true -Dpackaging=jar -DgroupId=com.sun.jini \
-DartifactId=reggie -Dfile=apache-river/lib/reggie.jar -DpomFile=maven2/reggie.pom -DuniqueVersion=false \
-DrepositoryId=rio -Durl=scp://...
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759871#action_12759871 ]
Peter Firmstone commented on RIVER-317:
---------------------------------------
I've committed the patch, so we can check it, sort it and release it with AR2.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-317) Deploy Apache River artifacts to Maven
repositories (both release and snapshot)
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-317:
----------------------------------
Fix Version/s: (was: AR2)
AR3
Postpone until AR3, clearing AR2 for release.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR3
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
Right .. I've read the releasing guidelines in the mean time.
My intentions with previous message was actually to induce a vote here :-)
I would just like this to move this forward (I think everybody does).
Sorry for giving maybe the wrong signals ...
2009/10/1 Niclas Hedhman <ni...@hedhman.org>
> Well, as you can see in the docs, "release" is a process of creating the
> artifacts for the community to test, review and the VOTE (that vote is
> starting should be announced to the Incubator PMC, i.e. general@ list)
> upon.
> Once successful vote here, a VOTE is also needed by the Incubator PMC.
>
> Not until that vote is successful are allowed to "publish" the release to
> the general public, such as download page on website or Maven repositories.
>
> Hope that clarifies the workflow a bit...
>
> -- Niclas
>
> On Oct 1, 2009 8:16 PM, "Jonathan Costers" <
> jonathan.costers@googlemail.com>
> wrote:
>
> I would definately NOT back out the POMs that were committed before. They
> are an excellent starting point for eventually publishing River artifacts
> to
> Maven repositories.
> Let's finish the discussion about the -dl JARs, but let's release first.
>
> If everyone agrees, I'll change the version number from 2.1.1 to 2.2.0 in
> the Ant build (when I get home tonight) and let Hudson pick it up.
> In about an hour after that we will have AR2 aka River 2.2.0.
>
> Getting AR2 out also means:
> - publishing the artifacts to the River web site
> - updating docs?
> - announcing it
>
> Thanks
> Jonathan
>
> 2009/10/1 Peter Firmstone <ji...@zeus.net.au>
>
> > By the sound of what Dennis is saying, it appears more to be a >
> classification issue rather than...
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Niclas Hedhman <ni...@hedhman.org>.
Well, as you can see in the docs, "release" is a process of creating the
artifacts for the community to test, review and the VOTE (that vote is
starting should be announced to the Incubator PMC, i.e. general@ list) upon.
Once successful vote here, a VOTE is also needed by the Incubator PMC.
Not until that vote is successful are allowed to "publish" the release to
the general public, such as download page on website or Maven repositories.
Hope that clarifies the workflow a bit...
-- Niclas
On Oct 1, 2009 8:16 PM, "Jonathan Costers" <jo...@googlemail.com>
wrote:
I would definately NOT back out the POMs that were committed before. They
are an excellent starting point for eventually publishing River artifacts to
Maven repositories.
Let's finish the discussion about the -dl JARs, but let's release first.
If everyone agrees, I'll change the version number from 2.1.1 to 2.2.0 in
the Ant build (when I get home tonight) and let Hudson pick it up.
In about an hour after that we will have AR2 aka River 2.2.0.
Getting AR2 out also means:
- publishing the artifacts to the River web site
- updating docs?
- announcing it
Thanks
Jonathan
2009/10/1 Peter Firmstone <ji...@zeus.net.au>
> By the sound of what Dennis is saying, it appears more to be a >
classification issue rather than...
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
I would definately NOT back out the POMs that were committed before. They
are an excellent starting point for eventually publishing River artifacts to
Maven repositories.
Let's finish the discussion about the -dl JARs, but let's release first.
If everyone agrees, I'll change the version number from 2.1.1 to 2.2.0 in
the Ant build (when I get home tonight) and let Hudson pick it up.
In about an hour after that we will have AR2 aka River 2.2.0.
Getting AR2 out also means:
- publishing the artifacts to the River web site
- updating docs?
- announcing it
Thanks
Jonathan
2009/10/1 Peter Firmstone <ji...@zeus.net.au>
> By the sound of what Dennis is saying, it appears more to be a
> classification issue rather than an issue with the pom's themselves.
>
> I'd also like to thank you Jeff for your effort.
>
> Getting the artefacts out there also means that there'll be people using
> them, if there are issues, they'll be sorted sooner.
>
> Anyone have any last minute changes before we unleash (just kidding, I'm in
> a good mood), I mean release River?
>
> The world has waited long enough. Jukka, you still happy to assist with the
> process?
>
> Cheers,
>
> Peter.
>
>
> Jim Waldo wrote:
>
>> I agree as well. Let's get something out.
>>
>> Jim
>>
>> On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
>>
>> Hi,
>>>
>>> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com> wrote:
>>>
>>>> If the current poms do 50% (number chosen at random) of what we want
>>>> them to do,
>>>> then fine. My personal opinion is that it would be a bit demoralising
>>>> to back them
>>>> out because they're not "perfect" when we can include a valuable
>>>> contribution and
>>>> make them "perfect" in the next release.
>>>>
>>>
>>> +1 Incremental improvement is a key to success.
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>>
>>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Jeff Ramsdale wrote:
> Hey Peter,
>
> On Thu, Oct 1, 2009 at 4:41 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> By the sound of what Dennis is saying, it appears more to be a
>> classification issue rather than an issue with the pom's themselves.
>>
>
> Yes.
>
>
>> I'd also like to thank you Jeff for your effort.
>>
>
> Most welcome!
>
>
>> Getting the artefacts out there also means that there'll be people using
>> them, if there are issues, they'll be sorted sooner.
>>
>> Anyone have any last minute changes before we unleash (just kidding, I'm in
>> a good mood), I mean release River?
>>
>
> This shouldn't impact a River release, but I don't think the poms
> belong in the src dir--rather, they should probably be at the root of
> the project. When the src dir is designated a Java source directory in
> Eclipse it makes it hard to navigate the poms since it tries to turn
> their parent directory structure into packages. Additionally, their
> current location suggests they should be in the classpath, which is
> not the case.
>
Ok Thanks Jeff.
>
>> The world has waited long enough. Jukka, you still happy to assist with the
>> process?
>>
>> Cheers,
>>
>> Peter.
>>
>
> Thanks for the help, Peter!
>
> -jeff
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jeff Ramsdale <je...@gmail.com>.
Hey Peter,
On Thu, Oct 1, 2009 at 4:41 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> By the sound of what Dennis is saying, it appears more to be a
> classification issue rather than an issue with the pom's themselves.
Yes.
> I'd also like to thank you Jeff for your effort.
Most welcome!
> Getting the artefacts out there also means that there'll be people using
> them, if there are issues, they'll be sorted sooner.
>
> Anyone have any last minute changes before we unleash (just kidding, I'm in
> a good mood), I mean release River?
This shouldn't impact a River release, but I don't think the poms
belong in the src dir--rather, they should probably be at the root of
the project. When the src dir is designated a Java source directory in
Eclipse it makes it hard to navigate the poms since it tries to turn
their parent directory structure into packages. Additionally, their
current location suggests they should be in the classpath, which is
not the case.
> The world has waited long enough. Jukka, you still happy to assist with the
> process?
>
> Cheers,
>
> Peter.
Thanks for the help, Peter!
-jeff
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Ok, Thanks Jukka.
Cheers,
Peter.
Jukka Zitting wrote:
> Hi,
>
> On Thu, Oct 1, 2009 at 1:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> The world has waited long enough. Jukka, you still happy to assist with the
>> process?
>>
>
> Yes, though I'll be mostly offline on vacation next week. Before and
> after that I'll help the best I can.
>
> To get started, see [1] and the referenced documentation under [2] for
> lots of instructions related to the Apache release process. Note that
> some of the documentation may not apply to River and might even be
> contradictory. Use common sense or ask when something is not clear.
>
> [1] http://incubator.apache.org/guides/releasemanagement.html
> [2] http://www.apache.org/dev/
>
> BR,
>
> Jukka Zitting
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Oct 1, 2009 at 1:41 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> The world has waited long enough. Jukka, you still happy to assist with the
> process?
Yes, though I'll be mostly offline on vacation next week. Before and
after that I'll help the best I can.
To get started, see [1] and the referenced documentation under [2] for
lots of instructions related to the Apache release process. Note that
some of the documentation may not apply to River and might even be
contradictory. Use common sense or ask when something is not clear.
[1] http://incubator.apache.org/guides/releasemanagement.html
[2] http://www.apache.org/dev/
BR,
Jukka Zitting
RE: Maven Artefacts RIVER-317 - AR2 Release
Posted by Tom Hobbs <to...@sucfin.com>.
> Anyone have any last minute changes before we unleash (just kidding,
I'm
> in a good mood), I mean release River?
Not me. No. None. Release release release! Go go go!
Sorry, just getting excited about the concept of having a new River
release.
Wow, silence from me for months and then three emails all in one day.
I'd better start pacing myself.
Tom
-----Original Message-----
From: Peter Firmstone [mailto:jini@zeus.net.au]
Sent: 01 October 2009 12:42
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
By the sound of what Dennis is saying, it appears more to be a
classification issue rather than an issue with the pom's themselves.
I'd also like to thank you Jeff for your effort.
Getting the artefacts out there also means that there'll be people using
them, if there are issues, they'll be sorted sooner.
Anyone have any last minute changes before we unleash (just kidding, I'm
in a good mood), I mean release River?
The world has waited long enough. Jukka, you still happy to assist with
the process?
Cheers,
Peter.
Jim Waldo wrote:
> I agree as well. Let's get something out.
>
> Jim
>
> On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com>
wrote:
>>> If the current poms do 50% (number chosen at random) of what we want
>>> them to do,
>>> then fine. My personal opinion is that it would be a bit
>>> demoralising to back them
>>> out because they're not "perfect" when we can include a valuable
>>> contribution and
>>> make them "perfect" in the next release.
>>
>> +1 Incremental improvement is a key to success.
>>
>> BR,
>>
>> Jukka Zitting
>
>
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
By the sound of what Dennis is saying, it appears more to be a
classification issue rather than an issue with the pom's themselves.
I'd also like to thank you Jeff for your effort.
Getting the artefacts out there also means that there'll be people using
them, if there are issues, they'll be sorted sooner.
Anyone have any last minute changes before we unleash (just kidding, I'm
in a good mood), I mean release River?
The world has waited long enough. Jukka, you still happy to assist with
the process?
Cheers,
Peter.
Jim Waldo wrote:
> I agree as well. Let's get something out.
>
> Jim
>
> On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
>
>> Hi,
>>
>> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com> wrote:
>>> If the current poms do 50% (number chosen at random) of what we want
>>> them to do,
>>> then fine. My personal opinion is that it would be a bit
>>> demoralising to back them
>>> out because they're not "perfect" when we can include a valuable
>>> contribution and
>>> make them "perfect" in the next release.
>>
>> +1 Incremental improvement is a key to success.
>>
>> BR,
>>
>> Jukka Zitting
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jim Waldo <Ji...@Sun.COM>.
I agree as well. Let's get something out.
Jim
On Oct 1, 2009, at 6:01 AM, Jukka Zitting wrote:
> Hi,
>
> On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com>
> wrote:
>> If the current poms do 50% (number chosen at random) of what we
>> want them to do,
>> then fine. My personal opinion is that it would be a bit
>> demoralising to back them
>> out because they're not "perfect" when we can include a valuable
>> contribution and
>> make them "perfect" in the next release.
>
> +1 Incremental improvement is a key to success.
>
> BR,
>
> Jukka Zitting
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Oct 1, 2009 at 10:58 AM, Tom Hobbs <to...@sucfin.com> wrote:
> If the current poms do 50% (number chosen at random) of what we want them to do,
> then fine. My personal opinion is that it would be a bit demoralising to back them
> out because they're not "perfect" when we can include a valuable contribution and
> make them "perfect" in the next release.
+1 Incremental improvement is a key to success.
BR,
Jukka Zitting
RE: Maven Artefacts RIVER-317 - AR2 Release
Posted by Tom Hobbs <to...@sucfin.com>.
If the poms are documented as to what they do and don't do then let's include them as-is (or with any outstanding bits of quick tidy-up that they need).
Making the poms do exactly what we need/want them to do could easily be included in the next major/minor/point release we decide to release anyway - is that not the point of releasing new software versions? It also fits a bit better with the "release little, release often" mantra.
Again, as long as the AR2 (or 2.0.0 or whatever it's called), release notes include comments along the lines of "Included maven repositories to get this JAR and this JAR, but not that JAR or that JAR", we're covered.
If the current poms do 50% (number chosen at random) of what we want them to do, then fine. My personal opinion is that it would be a bit demoralising to back them out because they're not "perfect" when we can include a valuable contribution and make them "perfect" in the next release.
My opinion; however wrong it might be. :-)
Cheers,
Tom
-----Original Message-----
From: Jeff Ramsdale [mailto:jeff.ramsdale@gmail.com]
Sent: 01 October 2009 01:52
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
If the poms are holding up a release then by all means revert the
poms--there's nothing stopping us from retroactively deploying River
artifacts via Maven. I do think it would be a mistake, though, to cut
a separate release just for Maven artifacts. Maven is simply another
way to release the artifacts that have already been released. That's
why I initially imagined deploying 2.1.1 to Maven.
-jeff
On Wed, Sep 30, 2009 at 5:42 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> What sort of time frame are we looking at for an implementation?
>
> Unless this can be done in the very near future, how about we reverse Jeff's
> Maven Patch for now, release River 2.2.0, patch it back into trunk and aim
> for a River 2.2.1 release that includes support for Maven artefacts?
>
> I'd like to get River 2.2.0 out the door.
>
> P.S. Excellent discussion, great to see...
>
> Cheers,
>
> Peter.
>
> Dennis Reedy wrote:
>>
>> Hi Gregg,
>>
>> To a certain extent I think having an archive would make sense, but as it
>> relates to Maven created service artifacts I am not so sure. I am going
>> through a conversion of Rio to a maven project, and am actively working on
>> better maven integration as well, so alot of what I reference below is an
>> ongoing effort. That being said, I think a high level discussion coud put
>> things in a better context. Lets discuss how something like Outrigger would
>> pan out:
>>
>> Outrigger would have the following artifacts:
>>
>> org.apache.river:outrigger -> This would map to outrigger.jar
>> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar. The
>> key here is creating this artifact with a classifier. The classifier allows
>> us to distinguish artifacts that were built from the same POM but differ in
>> their content.
>>
>> So if I have the groupId:artifactId[:classifier] I can get the jars from
>> the local repository (and/or download them from a configured repository).
>> Once we have that, we should be able to deploy directly from the local Maven
>> repository, having the classpath and codebase resolved by dependency
>> management.
>>
>> IMO, this could provide seamless integration with created service
>> artifact(s), and perhaps mitigate against creating service archives.
>>
>> Dennis
>>
>>
>> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
>>
>>> I am still of the opinion that we need to define a 'war' kind of archive
>>> of all the "jars" in a Jini service definition and make that the maven
>>> artifact (maybe use .jsd for the extension). Then, we need deployment tools
>>> that understand such a thing, and can open it and extract the bits out that
>>> are needed for each kind of use.
>>>
>>> I've thought about this some, and think that we could amend
>>> com.sun.jini.start to have another "config structure" that provided the
>>> appropriate details into the existing classes' construction inside of
>>> com.sun.jini.start.ServiceStarter.
>>>
>>> We might define the following '.jsd' file content from the top level
>>> directory perspective as a simple start.
>>>
>>> 1. META-INF/MANIFEST provides a class-path: entry that details the jars
>>> depended on for class path.
>>> 2. META-INF/MANIFEST provides a code-base: entry that details the names
>>> of jars that must be in the codebase
>>> 3. codebase/* contains all the codebase jars which are part of the build
>>> 4. service/* contains all of the jars which are part of the classpath
>>> 5. java.policy would provide a default policy file
>>>
>>> The 1 and 2 items would be what containers used to decide how to package
>>> a service. They would take provided jars out of 3 and 4 to fill out the
>>> details as the primary source.
>>>
>>> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
>>> artifact names would be a something to use here would it not? We could use
>>> different MANIFEST entries to specify simple jars vs known, public maven
>>> artifact names.
>>>
>>> There could also be stuff in the MANIFEST about version etc to help
>>> containers decide what version of what is needed.
>>>
>>> These are the things I've thought a little bit about so far. I've been
>>> working on the start of a netbeans plugin to try and deal with testing and
>>> using Jini services inside of netbeans and providing the generation of a
>>> 'war' kind of thing. It's going fairly well so far, but real work keeps
>>> taking precedence. This defined 'packaging' would make such a plug-in
>>> container neutral. Containers would then just need to provide a
>>> "JiniServiceDeployer" implementing plug-in to allow new services to be
>>> deployed out of the IDE.
>>>
>>> What do the other container authors think about this. Would it be more
>>> work to do something like this without a real benefit, or is there something
>>> we can all gain by creating some standard packaging to help keep things
>>> together and allow service "owners" to create deployment packages more
>>> readily for public consumption in various kinds of container environments?
>>>
>>> Gregg Wonderly
>>>
>>> Jonathan Costers wrote:
>>>>
>>>> Sorry, I actually need to thank Jeff for his contribution and Dennis for
>>>> his suggestions and remarks.
>>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>>>> Firmstone:
>>>>>
>>>>> Jeff contributed a patch containing pom's for the River dist jar files,
>>>>> which I've added to the main trunk, however it isn't clear how the download
>>>>> files for service clients are handled, Dennis has made some suggestions,
>>>>> however I'm going to need some help with this.
>>>>>
>>>>> Feel free to check out and have a play.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Patrick Wright wrote:
>>>>>>
>>>>>> Hi Peter
>>>>>>
>>>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>>>> along are you in creating the POM(s) for the build system? What is
>>>>>> missing?
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Patrick
>>>>>>
>>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au>
>>>>>> wrote:
>>>>>>
>>>>>>> Anyone have any ideas or willing to assist with patches? It'd be
>>>>>>> nice to
>>>>>>> have this complete for AR2.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>>
>>>>>>>> [
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>>>> ]
>>>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>>>> ------------------------------------
>>>>>>>>
>>>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>>>> approach. How
>>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>>>> defined?
>>>>>>>> With River services we have multiple artifacts per service, an
>>>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>>>> service ui
>>>>>>>> jar.
>>>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>>>> example, if I
>>>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>>>> outrigger.jar
>>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger)
>>>>>>>> needs to
>>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>>>
>>>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>>>> account
>>>>>>>> for how a maven project will use the artifacts.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Deploy Apache River artifacts to Maven repositories (both release
>>>>>>>>> and
>>>>>>>>> snapshot)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: RIVER-317
>>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>>>> Project: River
>>>>>>>>> Issue Type: Task
>>>>>>>>> Components: Web site and infrastructure
>>>>>>>>> Affects Versions: AR2, AR3
>>>>>>>>> Reporter: Jeff Ramsdale
>>>>>>>>> Fix For: AR2
>>>>>>>>>
>>>>>>>>> Attachments: river-poms.patch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be valuable if Apache River artifacts were deployed to a
>>>>>>>>> Maven
>>>>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>>>>> were
>>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>>> See thread:
>>>>>>>>>
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>>
>
>
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jeff Ramsdale <je...@gmail.com>.
If the poms are holding up a release then by all means revert the
poms--there's nothing stopping us from retroactively deploying River
artifacts via Maven. I do think it would be a mistake, though, to cut
a separate release just for Maven artifacts. Maven is simply another
way to release the artifacts that have already been released. That's
why I initially imagined deploying 2.1.1 to Maven.
-jeff
On Wed, Sep 30, 2009 at 5:42 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> What sort of time frame are we looking at for an implementation?
>
> Unless this can be done in the very near future, how about we reverse Jeff's
> Maven Patch for now, release River 2.2.0, patch it back into trunk and aim
> for a River 2.2.1 release that includes support for Maven artefacts?
>
> I'd like to get River 2.2.0 out the door.
>
> P.S. Excellent discussion, great to see...
>
> Cheers,
>
> Peter.
>
> Dennis Reedy wrote:
>>
>> Hi Gregg,
>>
>> To a certain extent I think having an archive would make sense, but as it
>> relates to Maven created service artifacts I am not so sure. I am going
>> through a conversion of Rio to a maven project, and am actively working on
>> better maven integration as well, so alot of what I reference below is an
>> ongoing effort. That being said, I think a high level discussion coud put
>> things in a better context. Lets discuss how something like Outrigger would
>> pan out:
>>
>> Outrigger would have the following artifacts:
>>
>> org.apache.river:outrigger -> This would map to outrigger.jar
>> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar. The
>> key here is creating this artifact with a classifier. The classifier allows
>> us to distinguish artifacts that were built from the same POM but differ in
>> their content.
>>
>> So if I have the groupId:artifactId[:classifier] I can get the jars from
>> the local repository (and/or download them from a configured repository).
>> Once we have that, we should be able to deploy directly from the local Maven
>> repository, having the classpath and codebase resolved by dependency
>> management.
>>
>> IMO, this could provide seamless integration with created service
>> artifact(s), and perhaps mitigate against creating service archives.
>>
>> Dennis
>>
>>
>> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
>>
>>> I am still of the opinion that we need to define a 'war' kind of archive
>>> of all the "jars" in a Jini service definition and make that the maven
>>> artifact (maybe use .jsd for the extension). Then, we need deployment tools
>>> that understand such a thing, and can open it and extract the bits out that
>>> are needed for each kind of use.
>>>
>>> I've thought about this some, and think that we could amend
>>> com.sun.jini.start to have another "config structure" that provided the
>>> appropriate details into the existing classes' construction inside of
>>> com.sun.jini.start.ServiceStarter.
>>>
>>> We might define the following '.jsd' file content from the top level
>>> directory perspective as a simple start.
>>>
>>> 1. META-INF/MANIFEST provides a class-path: entry that details the jars
>>> depended on for class path.
>>> 2. META-INF/MANIFEST provides a code-base: entry that details the names
>>> of jars that must be in the codebase
>>> 3. codebase/* contains all the codebase jars which are part of the build
>>> 4. service/* contains all of the jars which are part of the classpath
>>> 5. java.policy would provide a default policy file
>>>
>>> The 1 and 2 items would be what containers used to decide how to package
>>> a service. They would take provided jars out of 3 and 4 to fill out the
>>> details as the primary source.
>>>
>>> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
>>> artifact names would be a something to use here would it not? We could use
>>> different MANIFEST entries to specify simple jars vs known, public maven
>>> artifact names.
>>>
>>> There could also be stuff in the MANIFEST about version etc to help
>>> containers decide what version of what is needed.
>>>
>>> These are the things I've thought a little bit about so far. I've been
>>> working on the start of a netbeans plugin to try and deal with testing and
>>> using Jini services inside of netbeans and providing the generation of a
>>> 'war' kind of thing. It's going fairly well so far, but real work keeps
>>> taking precedence. This defined 'packaging' would make such a plug-in
>>> container neutral. Containers would then just need to provide a
>>> "JiniServiceDeployer" implementing plug-in to allow new services to be
>>> deployed out of the IDE.
>>>
>>> What do the other container authors think about this. Would it be more
>>> work to do something like this without a real benefit, or is there something
>>> we can all gain by creating some standard packaging to help keep things
>>> together and allow service "owners" to create deployment packages more
>>> readily for public consumption in various kinds of container environments?
>>>
>>> Gregg Wonderly
>>>
>>> Jonathan Costers wrote:
>>>>
>>>> Sorry, I actually need to thank Jeff for his contribution and Dennis for
>>>> his suggestions and remarks.
>>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>>>> Firmstone:
>>>>>
>>>>> Jeff contributed a patch containing pom's for the River dist jar files,
>>>>> which I've added to the main trunk, however it isn't clear how the download
>>>>> files for service clients are handled, Dennis has made some suggestions,
>>>>> however I'm going to need some help with this.
>>>>>
>>>>> Feel free to check out and have a play.
>>>>>
>>>>> Thanks in advance,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Patrick Wright wrote:
>>>>>>
>>>>>> Hi Peter
>>>>>>
>>>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>>>> along are you in creating the POM(s) for the build system? What is
>>>>>> missing?
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Patrick
>>>>>>
>>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au>
>>>>>> wrote:
>>>>>>
>>>>>>> Anyone have any ideas or willing to assist with patches? It'd be
>>>>>>> nice to
>>>>>>> have this complete for AR2.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>>
>>>>>>>> [
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>>>> ]
>>>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>>>> ------------------------------------
>>>>>>>>
>>>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>>>> approach. How
>>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>>>> defined?
>>>>>>>> With River services we have multiple artifacts per service, an
>>>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>>>> service ui
>>>>>>>> jar.
>>>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>>>> example, if I
>>>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>>>> outrigger.jar
>>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger)
>>>>>>>> needs to
>>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>>>
>>>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>>>> account
>>>>>>>> for how a maven project will use the artifacts.
>>>>>>>>
>>>>>>>>
>>>>>>>>> Deploy Apache River artifacts to Maven repositories (both release
>>>>>>>>> and
>>>>>>>>> snapshot)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: RIVER-317
>>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>>>> Project: River
>>>>>>>>> Issue Type: Task
>>>>>>>>> Components: Web site and infrastructure
>>>>>>>>> Affects Versions: AR2, AR3
>>>>>>>>> Reporter: Jeff Ramsdale
>>>>>>>>> Fix For: AR2
>>>>>>>>>
>>>>>>>>> Attachments: river-poms.patch
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be valuable if Apache River artifacts were deployed to a
>>>>>>>>> Maven
>>>>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>>>>> were
>>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>>> See thread:
>>>>>>>>>
>>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>>
>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
What sort of time frame are we looking at for an implementation?
Unless this can be done in the very near future, how about we reverse
Jeff's Maven Patch for now, release River 2.2.0, patch it back into
trunk and aim for a River 2.2.1 release that includes support for Maven
artefacts?
I'd like to get River 2.2.0 out the door.
P.S. Excellent discussion, great to see...
Cheers,
Peter.
Dennis Reedy wrote:
> Hi Gregg,
>
> To a certain extent I think having an archive would make sense, but as
> it relates to Maven created service artifacts I am not so sure. I am
> going through a conversion of Rio to a maven project, and am actively
> working on better maven integration as well, so alot of what I
> reference below is an ongoing effort. That being said, I think a high
> level discussion coud put things in a better context. Lets discuss
> how something like Outrigger would pan out:
>
> Outrigger would have the following artifacts:
>
> org.apache.river:outrigger -> This would map to outrigger.jar
> org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar.
> The key here is creating this artifact with a classifier. The
> classifier allows us to distinguish artifacts that were built from the
> same POM but differ in their content.
>
> So if I have the groupId:artifactId[:classifier] I can get the jars
> from the local repository (and/or download them from a configured
> repository). Once we have that, we should be able to deploy directly
> from the local Maven repository, having the classpath and codebase
> resolved by dependency management.
>
> IMO, this could provide seamless integration with created service
> artifact(s), and perhaps mitigate against creating service archives.
>
> Dennis
>
>
> On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
>
>> I am still of the opinion that we need to define a 'war' kind of
>> archive of all the "jars" in a Jini service definition and make that
>> the maven artifact (maybe use .jsd for the extension). Then, we need
>> deployment tools that understand such a thing, and can open it and
>> extract the bits out that are needed for each kind of use.
>>
>> I've thought about this some, and think that we could amend
>> com.sun.jini.start to have another "config structure" that provided
>> the appropriate details into the existing classes' construction
>> inside of com.sun.jini.start.ServiceStarter.
>>
>> We might define the following '.jsd' file content from the top level
>> directory perspective as a simple start.
>>
>> 1. META-INF/MANIFEST provides a class-path: entry that details the
>> jars depended on for class path.
>> 2. META-INF/MANIFEST provides a code-base: entry that details the
>> names of jars that must be in the codebase
>> 3. codebase/* contains all the codebase jars which are part of the
>> build
>> 4. service/* contains all of the jars which are part of the classpath
>> 5. java.policy would provide a default policy file
>>
>> The 1 and 2 items would be what containers used to decide how to
>> package a service. They would take provided jars out of 3 and 4 to
>> fill out the details as the primary source.
>>
>> Any missing jars from 3 and 4 would need to be obtained elsewhere.
>> Maven artifact names would be a something to use here would it not?
>> We could use different MANIFEST entries to specify simple jars vs
>> known, public maven artifact names.
>>
>> There could also be stuff in the MANIFEST about version etc to help
>> containers decide what version of what is needed.
>>
>> These are the things I've thought a little bit about so far. I've
>> been working on the start of a netbeans plugin to try and deal with
>> testing and using Jini services inside of netbeans and providing the
>> generation of a 'war' kind of thing. It's going fairly well so far,
>> but real work keeps taking precedence. This defined 'packaging' would
>> make such a plug-in container neutral. Containers would then just
>> need to provide a "JiniServiceDeployer" implementing plug-in to allow
>> new services to be deployed out of the IDE.
>>
>> What do the other container authors think about this. Would it be
>> more work to do something like this without a real benefit, or is
>> there something we can all gain by creating some standard packaging
>> to help keep things together and allow service "owners" to create
>> deployment packages more readily for public consumption in various
>> kinds of container environments?
>>
>> Gregg Wonderly
>>
>> Jonathan Costers wrote:
>>> Sorry, I actually need to thank Jeff for his contribution and Dennis
>>> for
>>> his suggestions and remarks.
>>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>>> Firmstone:
>>>> Jeff contributed a patch containing pom's for the River dist jar
>>>> files, which I've added to the main trunk, however it isn't clear
>>>> how the download files for service clients are handled, Dennis has
>>>> made some suggestions, however I'm going to need some help with this.
>>>>
>>>> Feel free to check out and have a play.
>>>>
>>>> Thanks in advance,
>>>>
>>>> Peter.
>>>>
>>>> Patrick Wright wrote:
>>>>> Hi Peter
>>>>>
>>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>>> along are you in creating the POM(s) for the build system? What is
>>>>> missing?
>>>>>
>>>>>
>>>>> Thanks
>>>>> Patrick
>>>>>
>>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone
>>>>> <ji...@zeus.net.au> wrote:
>>>>>
>>>>>> Anyone have any ideas or willing to assist with patches? It'd be
>>>>>> nice to
>>>>>> have this complete for AR2.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Peter.
>>>>>>
>>>>>> Dennis Reedy (JIRA) wrote:
>>>>>>
>>>>>>> [
>>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>>>
>>>>>>> ]
>>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>>> ------------------------------------
>>>>>>>
>>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>>> approach. How
>>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>>> defined?
>>>>>>> With River services we have multiple artifacts per service, an
>>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>>> service ui
>>>>>>> jar.
>>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>>> example, if I
>>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>>> outrigger.jar
>>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger)
>>>>>>> needs to
>>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>>
>>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>>> account
>>>>>>> for how a maven project will use the artifacts.
>>>>>>>
>>>>>>>
>>>>>>>> Deploy Apache River artifacts to Maven repositories (both
>>>>>>>> release and
>>>>>>>> snapshot)
>>>>>>>>
>>>>>>>> -------------------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>> Key: RIVER-317
>>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>>> Project: River
>>>>>>>> Issue Type: Task
>>>>>>>> Components: Web site and infrastructure
>>>>>>>> Affects Versions: AR2, AR3
>>>>>>>> Reporter: Jeff Ramsdale
>>>>>>>> Fix For: AR2
>>>>>>>>
>>>>>>>> Attachments: river-poms.patch
>>>>>>>>
>>>>>>>>
>>>>>>>> It would be valuable if Apache River artifacts were deployed to
>>>>>>>> a Maven
>>>>>>>> repository upon release. It would be even better if snapshot
>>>>>>>> builds were
>>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>>> See thread:
>>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
>
>
Packaging and deployment issues
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gregg, you wanted to open a discussion on Packaging and Deployment
issues, perhaps this should be raised as an issue on JIRA?
Its quite a complex issue, I'm not surprised it didn't garner much
response for that reason, however it is an issue that will need to be
dealt with sooner or later. I certainly don't know the solution,
however if we can work out what the constraints are, the pros and cons
and possible returns / benefits for each we might be able to address the
issue?
Cheers,
Peter.
Gregg Wonderly wrote:
> Dennis Reedy wrote:
>> Hi Gregg,
>>
>> To a certain extent I think having an archive would make sense, but
>> as it relates to Maven created service artifacts I am not so sure.
>
> I am not trying to focus this issue on solving anything related to
> maven. Instead, I am trying to discover what people think about
> creating an archive structure that could then be used for service
> deployment into various environments. Clearly, we could provide an
> archive assembler that used maven for managing the content of what was
> placed in the archive.
>
> The generation of the archive is one issue. But, on the other end is
> the consumption, and that's where I'd like to initially focus the
> discussion. I think that if we feel like it is something that the
> containers and deployment environments could use, and benefit from,
> than we can talk about providing such archives as a maven component
> from the river build.
>
> I'd like to discuss deployment issues regarding packaging, managing
> various pieces of a service deployment in particular environments, and
> solutions people have put together to see if there really is a place
> for such a thing, or if I'm just barking up the wrong tree.
>
> Gregg Wonderly
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Dennis Reedy <de...@gmail.com>.
On Oct 1, 2009, at 307PM, Gregg Wonderly wrote:
> Dennis Reedy wrote:
>> Hi Gregg,
>> To a certain extent I think having an archive would make sense, but
>> as it relates to Maven created service artifacts I am not so sure.
>
> I am not trying to focus this issue on solving anything related to
> maven.
Okay, perhaps I assumed your response had something to do with Maven
since was part of this thread. FWIW, I suggest you break it out of
this thread and start a new topic.
Re: Service Archive Structure (was: RE: Maven Artefacts RIVER-317 -
AR2 Release)
Posted by Patrick Wright <pd...@gmail.com>.
Hi
I also think this is a good direction to go in, and would benefit from
group discussion (and action :)).
Personally, I think it would help if we focused on a handful for
specific, widely-applicable use cases/deployment targets. What I mean
is that for example, in my work environment it's hard to get people to
accept a new type of service container or service container model. But
if I say, this service can be packaged as a WAR, or it's just a Java
app that can be started on its own (e.g. with Java Service Wrapper),
then they will go along with it. I think there is a target "market"
for service-oriented/distributed apps which rely on mainstream Java
container/server technologies. That won't address all of the River
community's interests, but I believe this offers us the opportunity to
extend the community to those who would otherwise be considering
something like the Web Services stack or JEE.
I'm not saying that River as a whole needs to move in that direction,
but that it should driven by a sort of partner community/subproject. I
know from previous discussions on the mailing lists that there are
those that don't want to see Jini be pushed/promoted as just another
alternative to web services and JEE, and I agree that the vision and
capabilities of Jini include much more than that. But it is a market
which I, for example, ended up working in, and so I'd like to promote
that use-case. I also think that the previous community experiments
with one central Jini/JavaSpaces project and any number of external
projects doing their own thing hasn't worked out that well. Most, if
not all of the Jini-based service container/deployment projects are
run by one developer. I think only Rio has a sizable community in that
space. It would be better, IMO, if River had a sub-project for
container deployment, perhaps with a set of standards, e.g. around
annotations, configuration, and allowed/supported different
implementations. There is a lot of useful and usable code in the
various sister projects (Rio, Bantam, Seven, reef, etc.) which we
could use as a starting point.
Off the top of my head, some important goals/features would be
- Deployment to "standard" web containers, basically anything
supporting either basic Java web stack (servlet/JSP) or full JEE; this
would include servers like Tomcat, Glassfish, Jetty, Resin, etc.
Should work out of the box with a "standard" deployment package like a
WAR, EAR or SAR.
- LUS and codebase servers packaged for the same type of deployment
- Optional "simple server" startup outside of a container using Java
Service Wrapper (open source, cross-platform, includes watchdog
process, configurable, etc.) or equivalent
- Annotation-based "lightweight" service declaration--the whole JEE
and web services stacks are moving in this direction
- Automated DL JAR building either at compile time or at runtime
- Utilities (including command-line) to monitor lookup services,
health-check services for reachability, etc.
- Standard JMX beans to monitor and configure services
I'd add that it's important to provide a simple alternative to the
external Jini-specific config files. Something like Mayflower is one
direction to go in (since it integrates with Spring)--note that there
is a dependency injection API that will likely be approved for JDK 7
and which will allow dynamic configuration implemented by e.g. Spring,
Guice or others.
Last point, there has been a sea change in server-side app development
for Java servers in the last few years, driven in part by the success
of Ruby on Rails. All of the standard frameworks and APIs are going in
the direction of annotation-based configuration, convention over
configuration, and lightweight setup. This doesn't just impact the
initial out-of-the-box experience, but also the scenario where your
team decides, "we need to split this out to another service" and need
to do it quickly, e.g. in a matter of days or a couple of weeks, not
of months.
Hope this is all not off-topic for the thread.
Regards
Patrick
Service Archive Structure (was: RE: Maven Artefacts RIVER-317 - AR2 Release)
Posted by Tom Hobbs <to...@sucfin.com>.
I think there is a lot of merit in this idea. Creating a standard
".jsd" that described where to put which files (and therefore, which
files are needed) would make River service creation and deployment much
simpler.
One of my frustrations is the sprinkling of different discrete files and
bits and bobs that are all required to start up a service. Of course,
once you're used to what is needed it becomes second nature, but
developing that second nature is a pain. As is troubleshooting when
your second natures lets you down!
However, defining an archive file structure that describes everything
you need - and presumably ant tasks and the maven equivalents, to
generate and start/stop these things - will make life a whole lot
easier.
Where I work, we have a concept of a grouping of services which can all
be started together, often in the same JVM. Any given host can run
multiple "service groups". We developed our own directory structure
which describes where everything goes, new "service groups" then use a
template of that directory structure. The problem with this, though, is
that the scripts are all OS specific and need constant configuring and
maintaining. Also, hand rolling a "service group" directory is error
prone (although made simpler with some Bash magic).
If I understand Gregg (do I?) developing a way to package a service or
services could be left to some, River supplied, automated tool.
Starting them then becomes a simple process of;
$ java com.sun.jini.start.ServiceStarter MyService.jsd
Or something.
I also like the idea of making a mechanism of dropping these ".jsd"
files into other container environments. Dare I say "OSGi"? And have
them handle the starting/stopping of them.
River is great in that you can do a whole heap of really clever and
amazing things with it. But speaking as an "app developer" who just
wants to write services that will live solely within his own companies
secure and safe subnet, River/Jini can be an absolute pain.
Again, if I understand it right, these ".jsd" files would take away much
of that pain. Right?
Great idea, Gregg. In my opinion, this is well worth a Jira of its own
and some serious thought/effort put into it.
Cheers,
Tom
-----Original Message-----
From: Gregg Wonderly [mailto:gregg@wonderly.org]
Sent: 01 October 2009 20:08
To: river-dev@incubator.apache.org
Subject: Re: Maven Artefacts RIVER-317 - AR2 Release
Dennis Reedy wrote:
> Hi Gregg,
>
> To a certain extent I think having an archive would make sense, but as
> it relates to Maven created service artifacts I am not so sure.
I am not trying to focus this issue on solving anything related to
maven.
Instead, I am trying to discover what people think about creating an
archive
structure that could then be used for service deployment into various
environments. Clearly, we could provide an archive assembler that used
maven
for managing the content of what was placed in the archive.
The generation of the archive is one issue. But, on the other end is
the
consumption, and that's where I'd like to initially focus the
discussion. I
think that if we feel like it is something that the containers and
deployment
environments could use, and benefit from, than we can talk about
providing such
archives as a maven component from the river build.
I'd like to discuss deployment issues regarding packaging, managing
various
pieces of a service deployment in particular environments, and solutions
people
have put together to see if there really is a place for such a thing, or
if I'm
just barking up the wrong tree.
Gregg Wonderly
www.sucdenfinancial.com
Sucden Financial Limited, Plantation Place South, 60 Great Tower Street, London EC3R 5AZ
Telephone +44 203 207 5000
Registered in England no. 1095841
VAT registration no. GB 446 9061 33
Authorised and Regulated by the Financial Services Authority (FSA) and entered in the FSA register under no. 114239
This email, including any files transmitted with it, is confidential and may be privileged. It may be read, copied and used only by the intended recipient. If you are not the intended recipient of this message, please notify postmaster@sucfin.com immediately and delete it from your computer system.
We believe, but do not warrant, that this email and its attachments are virus-free, but you should check.
Sucden Financial Limited may monitor traffic data of both business and personal emails. By replying to this email, you consent to Sucden Financial 's monitoring the content of any emails you send to or receive from Sucden Financial . Sucden Financial is not liable for any opinions expressed by the sender where this is a non-business email.
The contents of this e-mail do not constitute advice and should not be regarded as a recommendation to buy, sell or otherwise deal with any particular investment.
This message has been scanned for viruses by Mimecast.
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Gregg Wonderly <gr...@wonderly.org>.
Dennis Reedy wrote:
> Hi Gregg,
>
> To a certain extent I think having an archive would make sense, but as
> it relates to Maven created service artifacts I am not so sure.
I am not trying to focus this issue on solving anything related to maven.
Instead, I am trying to discover what people think about creating an archive
structure that could then be used for service deployment into various
environments. Clearly, we could provide an archive assembler that used maven
for managing the content of what was placed in the archive.
The generation of the archive is one issue. But, on the other end is the
consumption, and that's where I'd like to initially focus the discussion. I
think that if we feel like it is something that the containers and deployment
environments could use, and benefit from, than we can talk about providing such
archives as a maven component from the river build.
I'd like to discuss deployment issues regarding packaging, managing various
pieces of a service deployment in particular environments, and solutions people
have put together to see if there really is a place for such a thing, or if I'm
just barking up the wrong tree.
Gregg Wonderly
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Dennis Reedy <de...@gmail.com>.
Hi Gregg,
To a certain extent I think having an archive would make sense, but as
it relates to Maven created service artifacts I am not so sure. I am
going through a conversion of Rio to a maven project, and am actively
working on better maven integration as well, so alot of what I
reference below is an ongoing effort. That being said, I think a high
level discussion coud put things in a better context. Lets discuss
how something like Outrigger would pan out:
Outrigger would have the following artifacts:
org.apache.river:outrigger -> This would map to outrigger.jar
org.apache.river:outrigger:dl -> This would map to outrigger-dl.jar.
The key here is creating this artifact with a classifier. The
classifier allows us to distinguish artifacts that were built from the
same POM but differ in their content.
So if I have the groupId:artifactId[:classifier] I can get the jars
from the local repository (and/or download them from a configured
repository). Once we have that, we should be able to deploy directly
from the local Maven repository, having the classpath and codebase
resolved by dependency management.
IMO, this could provide seamless integration with created service
artifact(s), and perhaps mitigate against creating service archives.
Dennis
On Sep 30, 2009, at 635PM, Gregg Wonderly wrote:
> I am still of the opinion that we need to define a 'war' kind of
> archive of all the "jars" in a Jini service definition and make that
> the maven artifact (maybe use .jsd for the extension). Then, we
> need deployment tools that understand such a thing, and can open it
> and extract the bits out that are needed for each kind of use.
>
> I've thought about this some, and think that we could amend
> com.sun.jini.start to have another "config structure" that provided
> the appropriate details into the existing classes' construction
> inside of com.sun.jini.start.ServiceStarter.
>
> We might define the following '.jsd' file content from the top level
> directory perspective as a simple start.
>
> 1. META-INF/MANIFEST provides a class-path: entry that details the
> jars depended on for class path.
> 2. META-INF/MANIFEST provides a code-base: entry that details the
> names of jars that must be in the codebase
> 3. codebase/* contains all the codebase jars which are part of the
> build
> 4. service/* contains all of the jars which are part of the classpath
> 5. java.policy would provide a default policy file
>
> The 1 and 2 items would be what containers used to decide how to
> package a service. They would take provided jars out of 3 and 4 to
> fill out the details as the primary source.
>
> Any missing jars from 3 and 4 would need to be obtained elsewhere.
> Maven artifact names would be a something to use here would it not?
> We could use different MANIFEST entries to specify simple jars vs
> known, public maven artifact names.
>
> There could also be stuff in the MANIFEST about version etc to help
> containers decide what version of what is needed.
>
> These are the things I've thought a little bit about so far. I've
> been working on the start of a netbeans plugin to try and deal with
> testing and using Jini services inside of netbeans and providing the
> generation of a 'war' kind of thing. It's going fairly well so far,
> but real work keeps taking precedence. This defined 'packaging'
> would make such a plug-in container neutral. Containers would then
> just need to provide a "JiniServiceDeployer" implementing plug-in to
> allow new services to be deployed out of the IDE.
>
> What do the other container authors think about this. Would it be
> more work to do something like this without a real benefit, or is
> there something we can all gain by creating some standard packaging
> to help keep things together and allow service "owners" to create
> deployment packages more readily for public consumption in various
> kinds of container environments?
>
> Gregg Wonderly
>
> Jonathan Costers wrote:
>> Sorry, I actually need to thank Jeff for his contribution and
>> Dennis for
>> his suggestions and remarks.
>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>> Firmstone:
>>> Jeff contributed a patch containing pom's for the River dist jar
>>> files, which I've added to the main trunk, however it isn't clear
>>> how the download files for service clients are handled, Dennis
>>> has made some suggestions, however I'm going to need some help
>>> with this.
>>>
>>> Feel free to check out and have a play.
>>>
>>> Thanks in advance,
>>>
>>> Peter.
>>>
>>> Patrick Wright wrote:
>>>> Hi Peter
>>>>
>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>> along are you in creating the POM(s) for the build system? What is
>>>> missing?
>>>>
>>>>
>>>> Thanks
>>>> Patrick
>>>>
>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone
>>>> <ji...@zeus.net.au> wrote:
>>>>
>>>>> Anyone have any ideas or willing to assist with patches? It'd
>>>>> be nice to
>>>>> have this complete for AR2.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Dennis Reedy (JIRA) wrote:
>>>>>
>>>>>> [
>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>> ]
>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>> ------------------------------------
>>>>>>
>>>>>> I dont see how the -dl.jar files are being handled with this
>>>>>> approach. How
>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...)
>>>>>> be defined?
>>>>>> With River services we have multiple artifacts per service, an
>>>>>> implementation jar, a download (client) jar and potentially a
>>>>>> service ui
>>>>>> jar.
>>>>>> I suggest that we need to be thinking of adding classifiers for
>>>>>> the
>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>> example, if I
>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>> outrigger.jar
>>>>>> and outrigger-dl.jar, but my client (the one who uses
>>>>>> Outrigger) needs to
>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>
>>>>>> Declaring dependencies on River produced maven artifacts need
>>>>>> to account
>>>>>> for how a maven project will use the artifacts.
>>>>>>
>>>>>>
>>>>>>> Deploy Apache River artifacts to Maven repositories (both
>>>>>>> release and
>>>>>>> snapshot)
>>>>>>>
>>>>>>> -------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Key: RIVER-317
>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>> Project: River
>>>>>>> Issue Type: Task
>>>>>>> Components: Web site and infrastructure
>>>>>>> Affects Versions: AR2, AR3
>>>>>>> Reporter: Jeff Ramsdale
>>>>>>> Fix For: AR2
>>>>>>>
>>>>>>> Attachments: river-poms.patch
>>>>>>>
>>>>>>>
>>>>>>> It would be valuable if Apache River artifacts were deployed
>>>>>>> to a Maven
>>>>>>> repository upon release. It would be even better if snapshot
>>>>>>> builds were
>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>> See thread:
>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox
>>>>>>> /<e2...@mail.gmail.com>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
I am certainly not a container author .. But I find your thoughts very
interesting.
There has been discussion around deployment mechanisms before, IIRC (long
time ago)?
2009/10/1 Gregg Wonderly <gr...@wonderly.org>
> I am still of the opinion that we need to define a 'war' kind of archive of
> all the "jars" in a Jini service definition and make that the maven artifact
> (maybe use .jsd for the extension). Then, we need deployment tools that
> understand such a thing, and can open it and extract the bits out that are
> needed for each kind of use.
>
> I've thought about this some, and think that we could amend
> com.sun.jini.start to have another "config structure" that provided the
> appropriate details into the existing classes' construction inside of
> com.sun.jini.start.ServiceStarter.
>
> We might define the following '.jsd' file content from the top level
> directory perspective as a simple start.
>
> 1. META-INF/MANIFEST provides a class-path: entry that details the jars
> depended on for class path.
> 2. META-INF/MANIFEST provides a code-base: entry that details the names of
> jars that must be in the codebase
> 3. codebase/* contains all the codebase jars which are part of the build
> 4. service/* contains all of the jars which are part of the classpath
> 5. java.policy would provide a default policy file
>
> The 1 and 2 items would be what containers used to decide how to package a
> service. They would take provided jars out of 3 and 4 to fill out the
> details as the primary source.
>
> Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
> artifact names would be a something to use here would it not? We could use
> different MANIFEST entries to specify simple jars vs known, public maven
> artifact names.
>
> There could also be stuff in the MANIFEST about version etc to help
> containers decide what version of what is needed.
>
> These are the things I've thought a little bit about so far. I've been
> working on the start of a netbeans plugin to try and deal with testing and
> using Jini services inside of netbeans and providing the generation of a
> 'war' kind of thing. It's going fairly well so far, but real work keeps
> taking precedence. This defined 'packaging' would make such a plug-in
> container neutral. Containers would then just need to provide a
> "JiniServiceDeployer" implementing plug-in to allow new services to be
> deployed out of the IDE.
>
> What do the other container authors think about this. Would it be more
> work to do something like this without a real benefit, or is there something
> we can all gain by creating some standard packaging to help keep things
> together and allow service "owners" to create deployment packages more
> readily for public consumption in various kinds of container environments?
>
> Gregg Wonderly
>
>
> Jonathan Costers wrote:
>
>> Sorry, I actually need to thank Jeff for his contribution and Dennis for
>> his suggestions and remarks.
>>
>>
>> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
>> Firmstone:
>>
>>> Jeff contributed a patch containing pom's for the River dist jar files,
>>> which I've added to the main trunk, however it isn't clear how the download
>>> files for service clients are handled, Dennis has made some suggestions,
>>> however I'm going to need some help with this.
>>>
>>> Feel free to check out and have a play.
>>>
>>> Thanks in advance,
>>>
>>> Peter.
>>>
>>> Patrick Wright wrote:
>>>
>>>> Hi Peter
>>>>
>>>> Can you update us on the status of River vis-a-vis Maven? How far
>>>> along are you in creating the POM(s) for the build system? What is
>>>> missing?
>>>>
>>>>
>>>> Thanks
>>>> Patrick
>>>>
>>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au>
>>>> wrote:
>>>>
>>>>
>>>>> Anyone have any ideas or willing to assist with patches? It'd be nice
>>>>> to
>>>>> have this complete for AR2.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>> Dennis Reedy (JIRA) wrote:
>>>>>
>>>>>
>>>>>> [
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>>> ]
>>>>>> Dennis Reedy commented on RIVER-317:
>>>>>> ------------------------------------
>>>>>>
>>>>>> I dont see how the -dl.jar files are being handled with this approach.
>>>>>> How
>>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be
>>>>>> defined?
>>>>>> With River services we have multiple artifacts per service, an
>>>>>> implementation jar, a download (client) jar and potentially a service
>>>>>> ui
>>>>>> jar.
>>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>>> artifacts, allowing dependencies to be resolved correctly. For
>>>>>> example, if I
>>>>>> am using Outrigger, I need to be able to start Outrigger using
>>>>>> outrigger.jar
>>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs
>>>>>> to
>>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>>
>>>>>> Declaring dependencies on River produced maven artifacts need to
>>>>>> account
>>>>>> for how a maven project will use the artifacts.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Deploy Apache River artifacts to Maven repositories (both release and
>>>>>>> snapshot)
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------------------------------
>>>>>>>
>>>>>>> Key: RIVER-317
>>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>>> Project: River
>>>>>>> Issue Type: Task
>>>>>>> Components: Web site and infrastructure
>>>>>>> Affects Versions: AR2, AR3
>>>>>>> Reporter: Jeff Ramsdale
>>>>>>> Fix For: AR2
>>>>>>>
>>>>>>> Attachments: river-poms.patch
>>>>>>>
>>>>>>>
>>>>>>> It would be valuable if Apache River artifacts were deployed to a
>>>>>>> Maven
>>>>>>> repository upon release. It would be even better if snapshot builds
>>>>>>> were
>>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>>> See thread:
>>>>>>>
>>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/
>>>>>>> <e2...@mail.gmail.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Gregg Wonderly <gr...@wonderly.org>.
I am still of the opinion that we need to define a 'war' kind of archive of all
the "jars" in a Jini service definition and make that the maven artifact (maybe
use .jsd for the extension). Then, we need deployment tools that understand
such a thing, and can open it and extract the bits out that are needed for each
kind of use.
I've thought about this some, and think that we could amend com.sun.jini.start
to have another "config structure" that provided the appropriate details into
the existing classes' construction inside of com.sun.jini.start.ServiceStarter.
We might define the following '.jsd' file content from the top level directory
perspective as a simple start.
1. META-INF/MANIFEST provides a class-path: entry that details the jars
depended on for class path.
2. META-INF/MANIFEST provides a code-base: entry that details the names of jars
that must be in the codebase
3. codebase/* contains all the codebase jars which are part of the build
4. service/* contains all of the jars which are part of the classpath
5. java.policy would provide a default policy file
The 1 and 2 items would be what containers used to decide how to package a
service. They would take provided jars out of 3 and 4 to fill out the details as
the primary source.
Any missing jars from 3 and 4 would need to be obtained elsewhere. Maven
artifact names would be a something to use here would it not? We could use
different MANIFEST entries to specify simple jars vs known, public maven
artifact names.
There could also be stuff in the MANIFEST about version etc to help containers
decide what version of what is needed.
These are the things I've thought a little bit about so far. I've been working
on the start of a netbeans plugin to try and deal with testing and using Jini
services inside of netbeans and providing the generation of a 'war' kind of
thing. It's going fairly well so far, but real work keeps taking precedence.
This defined 'packaging' would make such a plug-in container neutral.
Containers would then just need to provide a "JiniServiceDeployer" implementing
plug-in to allow new services to be deployed out of the IDE.
What do the other container authors think about this. Would it be more work to
do something like this without a real benefit, or is there something we can all
gain by creating some standard packaging to help keep things together and allow
service "owners" to create deployment packages more readily for public
consumption in various kinds of container environments?
Gregg Wonderly
Jonathan Costers wrote:
> Sorry, I actually need to thank Jeff for his contribution and Dennis for
> his suggestions and remarks.
>
>
> Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
> Firmstone:
>> Jeff contributed a patch containing pom's for the River dist jar files,
>> which I've added to the main trunk, however it isn't clear how the
>> download files for service clients are handled, Dennis has made some
>> suggestions, however I'm going to need some help with this.
>>
>> Feel free to check out and have a play.
>>
>> Thanks in advance,
>>
>> Peter.
>>
>> Patrick Wright wrote:
>>> Hi Peter
>>>
>>> Can you update us on the status of River vis-a-vis Maven? How far
>>> along are you in creating the POM(s) for the build system? What is
>>> missing?
>>>
>>>
>>> Thanks
>>> Patrick
>>>
>>> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>>>
>>>> Anyone have any ideas or willing to assist with patches? It'd be nice to
>>>> have this complete for AR2.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>> Dennis Reedy (JIRA) wrote:
>>>>
>>>>> [
>>>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>>>> ]
>>>>> Dennis Reedy commented on RIVER-317:
>>>>> ------------------------------------
>>>>>
>>>>> I dont see how the -dl.jar files are being handled with this approach. How
>>>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
>>>>> With River services we have multiple artifacts per service, an
>>>>> implementation jar, a download (client) jar and potentially a service ui
>>>>> jar.
>>>>> I suggest that we need to be thinking of adding classifiers for the
>>>>> artifacts, allowing dependencies to be resolved correctly. For example, if I
>>>>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
>>>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
>>>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>>>
>>>>> Declaring dependencies on River produced maven artifacts need to account
>>>>> for how a maven project will use the artifacts.
>>>>>
>>>>>
>>>>>> Deploy Apache River artifacts to Maven repositories (both release and
>>>>>> snapshot)
>>>>>>
>>>>>> -------------------------------------------------------------------------------
>>>>>>
>>>>>> Key: RIVER-317
>>>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>>>> Project: River
>>>>>> Issue Type: Task
>>>>>> Components: Web site and infrastructure
>>>>>> Affects Versions: AR2, AR3
>>>>>> Reporter: Jeff Ramsdale
>>>>>> Fix For: AR2
>>>>>>
>>>>>> Attachments: river-poms.patch
>>>>>>
>>>>>>
>>>>>> It would be valuable if Apache River artifacts were deployed to a Maven
>>>>>> repository upon release. It would be even better if snapshot builds were
>>>>>> also deployed to a snapshot repository by Hudson.
>>>>>> See thread:
>>>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
Sorry, I actually need to thank Jeff for his contribution and Dennis for
his suggestions and remarks.
Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
Firmstone:
> Jeff contributed a patch containing pom's for the River dist jar files,
> which I've added to the main trunk, however it isn't clear how the
> download files for service clients are handled, Dennis has made some
> suggestions, however I'm going to need some help with this.
>
> Feel free to check out and have a play.
>
> Thanks in advance,
>
> Peter.
>
> Patrick Wright wrote:
> > Hi Peter
> >
> > Can you update us on the status of River vis-a-vis Maven? How far
> > along are you in creating the POM(s) for the build system? What is
> > missing?
> >
> >
> > Thanks
> > Patrick
> >
> > On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> >
> >> Anyone have any ideas or willing to assist with patches? It'd be nice to
> >> have this complete for AR2.
> >>
> >> Cheers,
> >>
> >> Peter.
> >>
> >> Dennis Reedy (JIRA) wrote:
> >>
> >>> [
> >>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
> >>> ]
> >>> Dennis Reedy commented on RIVER-317:
> >>> ------------------------------------
> >>>
> >>> I dont see how the -dl.jar files are being handled with this approach. How
> >>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
> >>> With River services we have multiple artifacts per service, an
> >>> implementation jar, a download (client) jar and potentially a service ui
> >>> jar.
> >>> I suggest that we need to be thinking of adding classifiers for the
> >>> artifacts, allowing dependencies to be resolved correctly. For example, if I
> >>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
> >>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
> >>> only have outigger-dl.jar in it's classpath not outrigger.jar.
> >>>
> >>> Declaring dependencies on River produced maven artifacts need to account
> >>> for how a maven project will use the artifacts.
> >>>
> >>>
> >>>> Deploy Apache River artifacts to Maven repositories (both release and
> >>>> snapshot)
> >>>>
> >>>> -------------------------------------------------------------------------------
> >>>>
> >>>> Key: RIVER-317
> >>>> URL: https://issues.apache.org/jira/browse/RIVER-317
> >>>> Project: River
> >>>> Issue Type: Task
> >>>> Components: Web site and infrastructure
> >>>> Affects Versions: AR2, AR3
> >>>> Reporter: Jeff Ramsdale
> >>>> Fix For: AR2
> >>>>
> >>>> Attachments: river-poms.patch
> >>>>
> >>>>
> >>>> It would be valuable if Apache River artifacts were deployed to a Maven
> >>>> repository upon release. It would be even better if snapshot builds were
> >>>> also deployed to a snapshot repository by Hudson.
> >>>> See thread:
> >>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jeff Ramsdale <je...@gmail.com>.
I intended for the poms to correspond to the latest release at the
time they were contributed That is, I hoped the 2.1.1 release could be
deployed to the Maven repo since at the time I posted the poms AR2
wasn't in sight. I suppose if AR2 is released quickly it may not
matter that 2.1.1 isn't available in Maven. Also, I was targeting the
releases but since Hudson is now up again perhaps SNAPSHOT builds are
also a possibility.
BTW, are you able to provide source jars too? Would be great if we
could do a complete deployment...
I'm interested in whether the groupId/artifactId designations I gave
the artifacts are reasonable. Incidentally, I agree with Dennis that
the dl artifacts should be identified with classifiers, though I
hadn't had a chance to comment on that thread yet.
I'm going to kick off the version numbering as a separate topic.
-jeff
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Jonathan Costers <jo...@googlemail.com>.
I am investigating and experimenting using the contributed POMs (thanks
Dennis).
Currently, I have all artifacts deploying to a locally setup Maven
repository from the Ant build.xml, so that's good.
I have used the Maven Ant tasks - http://maven.apache.org/ant-tasks
Now the downside is this introduces a dependency on the Maven Ant tasks
JAR (Ant needs it in its classpath).
I believe the Ant instance Hudson uses to build has these tasks
installed, but I need to check to be sure.
Any thoughts on handling this dependency?
Another thing I would like to do is change the current version number of
the project to from 2.1.1 (which is actually incorrect, 2.1.1 was
released a long time ago) to 2.2-SNAPSHOT, to match the Maven artifact
version numbering (which makes a lot of sense anyway).
As soon as we decide to push out AR2, we can change this to 2.2.0?
Or should it be 2.2?
Comments on this?
Thanks
Jonathan
Op woensdag 30-09-2009 om 17:14 uur [tijdzone +1000], schreef Peter
Firmstone:
> Jeff contributed a patch containing pom's for the River dist jar files,
> which I've added to the main trunk, however it isn't clear how the
> download files for service clients are handled, Dennis has made some
> suggestions, however I'm going to need some help with this.
>
> Feel free to check out and have a play.
>
> Thanks in advance,
>
> Peter.
>
> Patrick Wright wrote:
> > Hi Peter
> >
> > Can you update us on the status of River vis-a-vis Maven? How far
> > along are you in creating the POM(s) for the build system? What is
> > missing?
> >
> >
> > Thanks
> > Patrick
> >
> > On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> >
> >> Anyone have any ideas or willing to assist with patches? It'd be nice to
> >> have this complete for AR2.
> >>
> >> Cheers,
> >>
> >> Peter.
> >>
> >> Dennis Reedy (JIRA) wrote:
> >>
> >>> [
> >>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
> >>> ]
> >>> Dennis Reedy commented on RIVER-317:
> >>> ------------------------------------
> >>>
> >>> I dont see how the -dl.jar files are being handled with this approach. How
> >>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
> >>> With River services we have multiple artifacts per service, an
> >>> implementation jar, a download (client) jar and potentially a service ui
> >>> jar.
> >>> I suggest that we need to be thinking of adding classifiers for the
> >>> artifacts, allowing dependencies to be resolved correctly. For example, if I
> >>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
> >>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
> >>> only have outigger-dl.jar in it's classpath not outrigger.jar.
> >>>
> >>> Declaring dependencies on River produced maven artifacts need to account
> >>> for how a maven project will use the artifacts.
> >>>
> >>>
> >>>> Deploy Apache River artifacts to Maven repositories (both release and
> >>>> snapshot)
> >>>>
> >>>> -------------------------------------------------------------------------------
> >>>>
> >>>> Key: RIVER-317
> >>>> URL: https://issues.apache.org/jira/browse/RIVER-317
> >>>> Project: River
> >>>> Issue Type: Task
> >>>> Components: Web site and infrastructure
> >>>> Affects Versions: AR2, AR3
> >>>> Reporter: Jeff Ramsdale
> >>>> Fix For: AR2
> >>>>
> >>>> Attachments: river-poms.patch
> >>>>
> >>>>
> >>>> It would be valuable if Apache River artifacts were deployed to a Maven
> >>>> repository upon release. It would be even better if snapshot builds were
> >>>> also deployed to a snapshot repository by Hudson.
> >>>> See thread:
> >>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
> >>>>
> >>>>
> >>>
> >>
> >
> >
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Jeff contributed a patch containing pom's for the River dist jar files,
which I've added to the main trunk, however it isn't clear how the
download files for service clients are handled, Dennis has made some
suggestions, however I'm going to need some help with this.
Feel free to check out and have a play.
Thanks in advance,
Peter.
Patrick Wright wrote:
> Hi Peter
>
> Can you update us on the status of River vis-a-vis Maven? How far
> along are you in creating the POM(s) for the build system? What is
> missing?
>
>
> Thanks
> Patrick
>
> On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Anyone have any ideas or willing to assist with patches? It'd be nice to
>> have this complete for AR2.
>>
>> Cheers,
>>
>> Peter.
>>
>> Dennis Reedy (JIRA) wrote:
>>
>>> [
>>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>>> ]
>>> Dennis Reedy commented on RIVER-317:
>>> ------------------------------------
>>>
>>> I dont see how the -dl.jar files are being handled with this approach. How
>>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
>>> With River services we have multiple artifacts per service, an
>>> implementation jar, a download (client) jar and potentially a service ui
>>> jar.
>>> I suggest that we need to be thinking of adding classifiers for the
>>> artifacts, allowing dependencies to be resolved correctly. For example, if I
>>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
>>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
>>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>>
>>> Declaring dependencies on River produced maven artifacts need to account
>>> for how a maven project will use the artifacts.
>>>
>>>
>>>> Deploy Apache River artifacts to Maven repositories (both release and
>>>> snapshot)
>>>>
>>>> -------------------------------------------------------------------------------
>>>>
>>>> Key: RIVER-317
>>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>>> Project: River
>>>> Issue Type: Task
>>>> Components: Web site and infrastructure
>>>> Affects Versions: AR2, AR3
>>>> Reporter: Jeff Ramsdale
>>>> Fix For: AR2
>>>>
>>>> Attachments: river-poms.patch
>>>>
>>>>
>>>> It would be valuable if Apache River artifacts were deployed to a Maven
>>>> repository upon release. It would be even better if snapshot builds were
>>>> also deployed to a snapshot repository by Hudson.
>>>> See thread:
>>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>>
>>>>
>>>
>>
>
>
Re: Maven Artefacts RIVER-317 - AR2 Release
Posted by Patrick Wright <pd...@gmail.com>.
Hi Peter
Can you update us on the status of River vis-a-vis Maven? How far
along are you in creating the POM(s) for the build system? What is
missing?
Thanks
Patrick
On Wed, Sep 30, 2009 at 8:48 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> Anyone have any ideas or willing to assist with patches? It'd be nice to
> have this complete for AR2.
>
> Cheers,
>
> Peter.
>
> Dennis Reedy (JIRA) wrote:
>>
>> [
>> https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243
>> ]
>> Dennis Reedy commented on RIVER-317:
>> ------------------------------------
>>
>> I dont see how the -dl.jar files are being handled with this approach. How
>> will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined?
>> With River services we have multiple artifacts per service, an
>> implementation jar, a download (client) jar and potentially a service ui
>> jar.
>> I suggest that we need to be thinking of adding classifiers for the
>> artifacts, allowing dependencies to be resolved correctly. For example, if I
>> am using Outrigger, I need to be able to start Outrigger using outrigger.jar
>> and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to
>> only have outigger-dl.jar in it's classpath not outrigger.jar.
>>
>> Declaring dependencies on River produced maven artifacts need to account
>> for how a maven project will use the artifacts.
>>
>>>
>>> Deploy Apache River artifacts to Maven repositories (both release and
>>> snapshot)
>>>
>>> -------------------------------------------------------------------------------
>>>
>>> Key: RIVER-317
>>> URL: https://issues.apache.org/jira/browse/RIVER-317
>>> Project: River
>>> Issue Type: Task
>>> Components: Web site and infrastructure
>>> Affects Versions: AR2, AR3
>>> Reporter: Jeff Ramsdale
>>> Fix For: AR2
>>>
>>> Attachments: river-poms.patch
>>>
>>>
>>> It would be valuable if Apache River artifacts were deployed to a Maven
>>> repository upon release. It would be even better if snapshot builds were
>>> also deployed to a snapshot repository by Hudson.
>>> See thread:
>>> http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>>
>>
>>
>
>
Maven Artefacts RIVER-317 - AR2 Release
Posted by Peter Firmstone <ji...@zeus.net.au>.
Anyone have any ideas or willing to assist with patches? It'd be nice
to have this complete for AR2.
Cheers,
Peter.
Dennis Reedy (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243 ]
>
> Dennis Reedy commented on RIVER-317:
> ------------------------------------
>
> I dont see how the -dl.jar files are being handled with this approach. How will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined? With River services we have multiple artifacts per service, an implementation jar, a download (client) jar and potentially a service ui jar.
>
> I suggest that we need to be thinking of adding classifiers for the artifacts, allowing dependencies to be resolved correctly. For example, if I am using Outrigger, I need to be able to start Outrigger using outrigger.jar and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to only have outigger-dl.jar in it's classpath not outrigger.jar.
>
> Declaring dependencies on River produced maven artifacts need to account for how a maven project will use the artifacts.
>
>
>> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
>> -------------------------------------------------------------------------------
>>
>> Key: RIVER-317
>> URL: https://issues.apache.org/jira/browse/RIVER-317
>> Project: River
>> Issue Type: Task
>> Components: Web site and infrastructure
>> Affects Versions: AR2, AR3
>> Reporter: Jeff Ramsdale
>> Fix For: AR2
>>
>> Attachments: river-poms.patch
>>
>>
>> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
>> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
>>
>
>
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Dennis Reedy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760243#action_12760243 ]
Dennis Reedy commented on RIVER-317:
------------------------------------
I dont see how the -dl.jar files are being handled with this approach. How will the -dl.jar files for reggie, outrigger, mahalo (etc...) be defined? With River services we have multiple artifacts per service, an implementation jar, a download (client) jar and potentially a service ui jar.
I suggest that we need to be thinking of adding classifiers for the artifacts, allowing dependencies to be resolved correctly. For example, if I am using Outrigger, I need to be able to start Outrigger using outrigger.jar and outrigger-dl.jar, but my client (the one who uses Outrigger) needs to only have outigger-dl.jar in it's classpath not outrigger.jar.
Declaring dependencies on River produced maven artifacts need to account for how a maven project will use the artifacts.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Jeff Ramsdale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758304#action_12758304 ]
Jeff Ramsdale commented on RIVER-317:
-------------------------------------
Ping. Could I get some feedback on these? How can we move forward?
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-317) Deploy Apache River artifacts to Maven
repositories (both release and snapshot)
Posted by "Jeff Ramsdale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jeff Ramsdale updated RIVER-317:
--------------------------------
Attachment: river-poms.patch
I've created a set of basic poms for what I understand to be the Apache River artifacts of greatest interest--that is, all the core and standard service artifacts. Of course the poms perform no build function for Apache River (although they could lead to that...)--they simply are meant to aid in deployment of the artifacts to Maven repositories. I did capture the artifact dependencies based on the contents of their respective manifest files.
I named all the artifacts with groupId: org.apache.river. There are earlier artifacts in the central repository under com.sun.jini, net.jini, jini, and possibly others. I thought preparing for the next release with the new path made sense, even if internally the old package names remain. This may require some discussion.
There should also be some discussion around where these artifacts are deployed. Some projects at Apache seem to be embracing the Nexus repository at https://repository.apache.org/index.html. See: https://issues.apache.org/jira/browse/INFRA-1896 for more details. I, myself, am a fan of Nexus and would favor deploying Apache River artifacts there.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Jeff Ramsdale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761065#action_12761065 ]
Jeff Ramsdale commented on RIVER-317:
-------------------------------------
I agree with everything Dennis says above.
I suppose the only option is to have another set of poms for the dl jars? Trying to set up some sort of automation would be more trouble than it's worth, I imagine... I'll try to work on these...
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759865#action_12759865 ]
Peter Firmstone commented on RIVER-317:
---------------------------------------
Are the *-dl.jar files I see in the patch maven artifacts? If so wouldn't these be downloaded dynamically by the jini/River client?
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Jeff Ramsdale (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761111#action_12761111 ]
Jeff Ramsdale commented on RIVER-317:
-------------------------------------
Now that I think about it, though, isn't it possible that the dl jar would have different dependencies? If you were to use these in a Maven context would you want to bring along transitive dependencies that came from the non-dl jar's pom if it were shared?
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758627#action_12758627 ]
Peter Firmstone commented on RIVER-317:
---------------------------------------
Hi Jeff,
I have very little experience with maven, reading your patch, it looks like you know what your doing, I can't see any problems uploading Apache River artifacts to Nexus, this seems like a good idea.
I don't have any objections to merging the patch, if it doesn't cause any issues with the existing build.
Anyone else care to comment?
Regards,
Peter.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786573#action_12786573 ]
Peter Firmstone commented on RIVER-317:
---------------------------------------
Does anybody have some time to devote to this issue, it's marked for an AR2 release, I'd like to either resolve the issue now or postpone it until after AR2.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-317) Deploy Apache River artifacts to
Maven repositories (both release and snapshot)
Posted by "Dennis Reedy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761187#action_12761187 ]
Dennis Reedy commented on RIVER-317:
------------------------------------
Not only is it possible, but it will happen most all the time. But here is the issue with this:
Even if you break out a different module for the -dl.jar, the -dl.jar will have a dependency on the impl jar, since it is a subset of the impl jar. So you are stuck with either duplicating the sources that end up in the -dl.jar, or declaring that the -dl.jar has a dependency on the impl jar.
In resolving the -dl jar's dependencies, the impl jar comes along, including all of it's transitive dependencies. This isnt exactly right, since the -dl.jar only requires the impl jar in order to run classdepandjar on it.
I think it comes down to whether this is more of an assembly issue. IMO, having one pom for a service that produces > 1 artifacts that in turn declares dependencies on other services (with classifiers where appropriate) seems to be the right way to go. I think it could get very confusing (not that this is all crystal clear) having a service devolve into a multi-module entity.
> Deploy Apache River artifacts to Maven repositories (both release and snapshot)
> -------------------------------------------------------------------------------
>
> Key: RIVER-317
> URL: https://issues.apache.org/jira/browse/RIVER-317
> Project: River
> Issue Type: Task
> Components: Web site and infrastructure
> Affects Versions: AR2, AR3
> Reporter: Jeff Ramsdale
> Fix For: AR2
>
> Attachments: river-poms.patch
>
>
> It would be valuable if Apache River artifacts were deployed to a Maven repository upon release. It would be even better if snapshot builds were also deployed to a snapshot repository by Hudson.
> See thread: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200908.mbox/<e2...@mail.gmail.com>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.