Re: Specs jars have not been rsynch'ed

[Brett Porter]

I'll fix the permissions by hand.

On 09/08/2007, at 2:01 AM, Tim McConnell wrote:

Hi Prasad, according to Joes2 on #asfinfra the permissions on those  
that I copied were incorrect. He changed them to 0775 (for dirs)  
and 0664 (for files). I'm not sure though if they'll resync  
automatically now or not though, and Joes2 did not know either.  
Does anyone know ??


Prasad Kashyap wrote:

Around 18+ hours ago we put some 3 artifacts in the
people.apache.org's rsynch repo to be released out to the world.
The artifacts in question are
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/ 
apache/geronimo/specs/geronimo-jacc_1.1_spec/1.0/
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/ 
apache/geronimo/specs/geronimo-jsp_2.1_spec/1.0/
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/ 
apache/geronimo/specs/geronimo-servlet_2.5_spec/1.1/

I am not entirely clear as to why we don't use maven's release plugin
yet. We used our own staging profile and then copy the artifacts by
hand to the above mentioned location. This has successfully worked so
far.
We need your help in rsynching the above artifacts. Geronimo 2.0 is
now up for a vote and it really depends on these artifacts to be
present out there.
Any and all help will be greatly appreciated.
Thanx
Prasad


--
Thanks,
Tim McConnell

XBean and VMBuild

[Brett Porter]

Hi,

I'm not on this list, so please reply directly - thanks.

XBean currently have a build set up in vmbuild.apache.org. It's been  
down for little bit, but is now back up.


vmbuild is scheduled to be moved to a faster machine, and I intend to  
install a more recent build of Continuum (that supports grouping  
projects and is generally faster, more managable and more stable).  
I'm able to help get it set up as effectively as possible.


There are a lot of failing builds on the machine right now (probably  
unused by the corresponding projects), so I'm cleaning house before  
the move.


Please let me know if:
[ ] you would like the project set up on the new machine with a clean  
slate
[ ] you would like the project (and it's build history if possible)  
moved over
[ ] you are no longer interested in using vmbuild for CI/nightlies/ 
whatever


Thanks!
- Brett

Re: Returning to Commit-Then-Review?

[Brett Porter]

From the peanut gallery...


On 23/08/06, David Blevins <[EMAIL PROTECTED]> wrote:

I'd be more inclined to talk about what we want to apply it to and how.

That said, I've stared at this email for an hour after writing the
above sentence and am still not sure what the answer would be

Part of me wouldn't mind seeing an RTC process where
  - it's not enforced. meaning we could pull the plug whenever we like


So, that would be RTC by lazy consensus? After 72 hours it gets
committed anyway if there are no -1's?


  - your +1 could simply mean you've reviewed it to your satisfaction
(whatever that means for you) and agree with the change.


I think I'd ask people to just +0 or say that to be clear so you know
how well tested it was. You don't want to be asking what their +1
really meant.


Tempted to also throw in "three +1s from any committer other than the
proposer are sufficient", but if that's going to be a topic of
debate, I'd rather see it put on hold and the first two items
implemented first.


The first one sort of allows this. I think anything that encourages
more committers to review is a good thing.

So, are you saying you don't think Geronimo is ready for CTR yet?

One thing that struck me is that if there was trouble getting reviews
done under RTC then its likely to be that CTR dissolves to just C :)
So perhaps some work on building a culture of review (including
ensuring enough committers have an eye on each area of the code) is
still helpful, with steps such as those you've highlighted. I know I
feel somewhat reassured that when I do something dumb in Maven that
someone always seems to find it.

Just my 2c.

Cheers,
Brett

Re: Frustrations of a Release Manager

[Brett Porter]

Funnily enough, GMail had this to offer at the top of my mail window:

"The way to get started is to quit talking and begin doing." - Walt Disney

(http://www.brainyquote.com/quotes/quotes/w/waltdisney131640.html)

:)

- Brett

On 15/06/06, Bruce Snyder <[EMAIL PROTECTED]> wrote:

On 6/14/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> I see a lot of whining in this thread an not a lot of coding.  If you
> ask me, if Jeff, John or anyone in the projects feels that we need an
> alternative to the javaplugins site, all they have to do is sit down
> and put together a site.  At that point we have have an open
> discussion on the default link.  We had a nice open discussion about
> the default link a while back and concluded it the javaplugins site
> was fine since there is only one site available, and when this state
> changes, I expect the default to change.
>
> Frankly, I think it is time to separate the talkers from the doers.

I tend to agree with these sentiments. The poor interactions on the
project lately have deteriorated far enough. What I really don't
understand is why so many people have such a knee-jerk reaction to
occurrences in the project anymore. It's as if everyone must interject
their opinion into every discussion no matter whether it adds value or
not. Face it, none of us can be aware of every single thing that is
being done within Geronimo. It's simply too big to mind every little
thing and be a part of every single point.

I also say enough jumping on the bandwagon to bash someone and what
they didn't do. Let's try to focus on the positives and if there are
negatives, talk about solutions instead of just bitching about the
problem because it's just not productive.

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/




--
Apache Maven - http://maven.apache.org
"Better Builds with Maven" book - http://library.mergere.com/

Re: Change to commit model for Apache Geronimo

[Brett Porter]

Umm, you guys do realise that there are already 4 people besides anita
that have said 'I don't think this requires RTC', who could just have
easily +1'd the RTC, right?

:)

Cheers,
Brett

On 02/06/06, John Sisson <[EMAIL PROTECTED]> wrote:

I agree that "merging" shouldn't require another RTC.  So merging of
your m2 migration changes should be OK.

We need to discuss the situation where merging a change from a branch to
trunk isn't a just a simple merge.  For example, manual changes needed
to be made, e.g. changes to logic because the trunk has moved in a
different direction to the branch you are merging from.  IMHO, in this
scenario, it would be worth discussing the changes on the dev list
before proceeding with the merge. Comments on this scenario?

John

Matt Hogstrom wrote:
> Prasad,
>
> I saw Anita's changes and started reviewing them.  Unfortunately, they
> required more time than I had at the moment and I won't get back to
> them until this weekend I suspect.
>
> I think that since this is a merge of existing work should not
> necessarily require review since it was existing and we've made the
> decision to have it merged forward.  The ROUS will probably need to
> comment here.  So long as Jaceck is overseeing the work that was
> previously committed I'm ok with not requiring RTC for this.
>
> Matt
>
> Prasad Kashyap wrote:
>> Anita has posted an [RTC] note with the patches to the devlist. She
>> had a question which I'm reposting it here for relevancy.
>>
>> A lot of patches for the m2 migration were reviewed and committed into
>> the now dead-1.2 branch (old trunk). This work should now go into the
>> new 1.2 trunk. So the same patches are being re-submitted. Should they
>> now be subjected to the new RTC guidelines ?
>>
>> Cheers
>> Prasad
>>
>> On 5/24/06, Bryan Noll <[EMAIL PROTECTED]> wrote:
>>> I'm one of the 3 Jeff was talking about.  You'll see some JIRA's coming
>>> in the next 24 hrs.
>>>
>>> John Sisson wrote:
>>> > Jeff Genender wrote:
>>> >> Matt,
>>> >>
>>> >> I know of 3 additional who are committed to helping with DT (me
>>> as one
>>> >> of the 3)...
>>> >>
>>> >> We have some nice patches coming up...
>>> >>
>>> >>
>>> > In the interests of being open and improving communications in the
>>> > Geronimo community, could you please create some JIRAs for the work
>>> > you are planning to do.
>>> >
>>> > Thanks,
>>> >
>>> > John
>>> >> Dunno if that helps :/
>>> >>
>>> >> Jeff
>>> >>
>>> >>
>>> >> Matt Hogstrom wrote:
>>> >>
>>> >>> I agree that it would be nice to get more committers looking and
>>> >>> working
>>> >>> on DayTrader as well as DevTools.  DayTrader we have been getting
>>> >>> additional activity so we are moving in the right direction.
>>> Since its
>>> >>> a performance/benchmark sample its very different than the
>>> server and
>>> >>> has a different constituency.  So, yes, its a problem however
>>> interest
>>> >>> is growing so the problem is become less of an issue.
>>> >>>
>>> >>> Greg Stein wrote:
>>> >>>
>>>  A shot from the peanut gallery... :-)
>>> 
>>>  Doesn't that seem like a problem? That maybe there should be more
>>>  people
>>>  involved? That it shouldn't be "I'm off in my corner working on
>>> this
>>>  stuff. With nobody else. I dunno how to get my +1 votes."
>>> 
>>>  IMO, part of Geronimo's issue is growing the community of
>>>  developers, and
>>>  especially the group of committers. You'll solve your problem if
>>>  you can
>>>  get more people working with you. And I think you'll solve many of
>>>  Geronimo's issues at the same time.
>>> 
>>>  IMO #2, I disagree with Ken's "patched in and tested" ... there
>>> are
>>>  many
>>>  changes that I've reviewed which I can give a +1 on just from
>>>  eyeballing
>>>  it. Or provide feedback on what needs to change. IOW, I don't
>>>  always need
>>>  a computer to tell me what it does. So I think it may be
>>> important to
>>>  request that Ken officially relaxes that requirement a bit :-)
>>> 
>>> >>> I think the above was the most significant concern I had since the
>>> >>> current lack of active participation (actually, folks really
>>> like the
>>> >>> app as it uncovers broken pieces in the server that need to be
>>> fixed) I
>>> >>> was concerned that getting people to install, test and validate was
>>> >>> going to be difficult.  If people can use their eyes thats
>>> fien.  Right
>>> >>> now its changing colors and packaging.
>>> >>>
>>> >>> IMHO DevTools is different in that few committers are running
>>> Eclipse
>>> >>> and working in that area so getting meaningful feedback will be
>>> >>> difficult.  I guess time will tell but I'd hate to see Sachin get
>>> >>> slowed
>>> >>> down.
>>> >>>
>>> >>>
>>>  Cheers,
>>>  -g
>>> 
>>>  On Tue, May 23, 2006 at 12:38:11PM -0400, Matt Hogstrom wrote:
>>> 
>>> > Ken, et al,
>>> >
>>> > I'm not sure about other people's feeling

Re: Yoko

[Brett Porter]

That list already exists.

- Brett

On 3/7/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> Alan D. Cabrera wrote, On 2/23/2006 12:59 PM:
>
> > On 2/23/2006 11:32 AM, Rodent of Unusual Size wrote:
> >
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Alan D. Cabrera wrote:
> >>
> >>
> >>> One question, do we need a PPMC?  I think that we should start one
> >>> since this project has a very real possibility of becoming a TLP.
> >>>
> >>
> >>
> >> It's not really a matter of choice.  Incubating podlings
> >> have PPMCs regardles of where they *might* end up.
> >>
> >> So, yes.  Next question, who should be on it?  The mentors
> >> have to be, but whom else?  I'm in favour of all of the
> >> committers, but that's just me. :-)
> >>
> >
> > Works for me.
>
>
> Ken,
>
> It seems that this is the way to go and has been "seconded" by lazy
> consensus.  I will file a Jira to create the
> [EMAIL PROTECTED] mailing list.
>
> This will be the last Yoko posting that crosses over to Geronimo and
> Incubator General.
>
>
>
> Regards,
> Alan
>
>
>
>
>
>
>

Re: Upgrade your M2 to the latest unstable version

[Brett Porter]

Jacek,

In case you haven't already, please declare this in the Geronimo root POM:


 2.0.3-SNAPSHOT


This will make the build fail with a friendly message on earlier versions.

- Brett

On 3/5/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Due to a couple of bugs in Maven 2.0.2 and to move forward with our
> migration to M2 it's necessary to upgrade it to today's build from
> http://maven.zones.apache.org/~maven/builds/trunk/m2-20060304.19.tar.gz.
>
> It seems to be the candidate for the next 2.0.3 release, which is
> being voted on maven-dev.
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>

magicGBall in Apache repo

[Brett Porter]

Hi,

Can someone describe what this is:

http://www.apache.org/dist/java-repository/magicGball/jars/

it doesn't look like something that is an official release?

- Brett

Re: PPMC for Yoko

[Brett Porter]

On 2/22/06, David Blevins <[EMAIL PROTECTED]> wrote:
> So when they graduate as subprojects of geronimo, how does that
> workout?  Does the PPMC just get dissolved?
>

s/when/if/
(both in sense of success and destination :)

I'd assume they all get added (or at least voted for) on the Geronimo PMC.

- Brett

Re: Ode proposal

[Brett Porter]

On 2/18/06, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> As far as i can remember, We started Harmony with Zero code and Zero
> committers...It's been done before :)

I suspect Geir was on there :) That's an unusual example given the
legal requirements of contributors.

> You are right, we need to set guidelines for selecting inital
> committers. Not sure where to start. ideas are welcome.

The other alternative is to add all 37 to lower the barrier to entry
and cut this back to the regular, recent contributors when it
graduates. Normally this would be too much of a burden on infra, but
AIUI these are mostly existing Apache committers.

Another similar alternative is to add those proposed by Sybase and
Intalio, and institute a rule that any servicemix/geronimo/WS/Agila
committers can request access at any time during incubation.

- Brett

Re: Migrating to maven 2 - conversion idea

[Brett Porter]

On 2/15/06, David Blevins <[EMAIL PROTECTED]> wrote:
> Every m2 project i've worked with eventually ended up leveraging
> maven 1 repositories.
>
> We'd likely use the maven-one-plugin which puts jars into a maven 1
> repo.  Also we'd likely still need to list cvs.apache.org in the repo
> list of our m2 build.

That's because they're all depending on snapshot versions of geronimo
dependencies :)

You will want to limit the number of snapshot repos you use, and
eventually remove dependence on m1 repos. I'd suggest mapping out
"what goes where" first. If all you are using is ibiblio, there is no
need to use the m1 version, as it is just a mapping over the m2 one.

Isn't the current Geronimo group ID "geronimo", so the new one can be
"org.apache.geronimo" without a clash?

- Brett

Re: Migrating to maven 2

[Brett Porter]

It'd make more sense to have m1 exec m2 so that your master build is
last to convert. This should be possible with .

Forking is probably slow, but forking m2 is probably faster than the
m1 build anyway :)

- Brett

On 2/15/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> If m2 could exec an m1 build (following global dependencies) or if m1
> could invoke m2, this conversion would be much easier as we could
> convert a module at at time.
>
> -dain
>
> On Feb 14, 2006, at 2:03 PM, Alan D. Cabrera wrote:
>
> > On 2/14/2006 3:09 AM, Anders Hessellund Jensen (Trifork) wrote:
> >
> >> I'd like to help migrating to maven 2.
> >>
> >> Where to start? I suppose a good start would be to write POM's for
> >> some of the modules. This should be fairly straightforward, at
> >> least for modules without complex jelly usage. Should the
> >> directory layout be configured to maven 1 style in the parent POM?
> >
> >
> > We've tried to do an uber move and it's never worked.  I recommend
> > that we move bits over one at a time.  Maybe we could kill two
> > birds with one stone and also perform the breakout that Aaron
> > proposed at the same time.
> >
> >
> >
> > Regards,
> > Alan
> >
> >
>
>

Re: Migrating Geronimo XDoclet2 plugin to Maven2

[Brett Porter]

You might want to contribute to
http://xdoclet.codehaus.org/Maven2+Plugin instead.

- Brett

On 2/10/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Since I'm at Maven2 learning path, I thought I could migrate the
> Geronimo XDoclet2 plugin to Maven2.
>
> Is there anything I should take into account before moving on? I'm
> going to work on it during the weekend.
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>

Re: Geronimo Specs for 1.0 only published to Maven 2 repo?

[Brett Porter]

cvs.apache.org/repository is for snapshots only an dis not mirrored.

www.apache.org/dist/java-repository is for releases and is both
mirrored as part of the normal release mirroring, and synced to
ibiblio.

- Brett

On 2/4/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> On 2/3/2006 2:57 PM, David Blevins wrote:
>
> >
> > On Feb 3, 2006, at 2:49 PM, Jason Dillon wrote:
> >
> >> Why aren't the spec jars for 1.0 published to the Maven 1 central repo
> >> in addition to the central Maven 2 repo?
> >>
> >
> > fyi,  http://www.apache.org/dist/java-repository/
> > org.apache.geronimo.specs/jars/
>
> Uh oh.  How is that different than the URL that I just mentioned?
>
>
> Regards,
> Alan
>
>
>
>

Re: Geronimo Specs for 1.0 only published to Maven 2 repo?

[Brett Porter]

The Maven 1 central repo *is* the maven 2 central repo. I expect they
just have a different group ID to what you expect.

I suggest all the old ones (and any releases inadvertently added)
should be removed from cvs.apache.org to have people move to the
released versions.

- Brett

On 2/4/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Why aren't the spec jars for 1.0 published to the Maven 1 central repo
> in addition to the central Maven 2 repo?
>
> --jason
>

Re: Move JAXB spec to Geronimo

[Brett Porter]

Since JaxMe is at Apache, you can move it over with svn mv.

Has the JaxMe community as a whole voted to do this? I think it makes
sense, it would just be good to ensure everyone agrees. It will also
impact the committer list for Geronimo.

Cheers,
Brett

On 12/14/05, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jochen Wiedmann wrote, On 12/14/2005 1:46 AM:
> > Hi,
> >
> > the JaxMe project contains a clean room implementation of the JAXB API
> > 1.1. As future versions of J2EE will contain the JAXB API, I propose
> > that these be moved to the other Geronimo J2EE spec implementations.
>
> Sounds great.  Let's put it in our geronimo/specs/trunk.  If it's
> stable, file a Jira w/ a tar of the files and I can plop that in.
>
>
> Regards,
> Alan
>
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDoGmq1xC6qnMLUpYRAthKAJ0XtFJgN4it+8ofXNyz+lfiUnRPmgCeJpAT
> rKGMkKyGI/NVQMvUMovXd9E=
> =guTU
> -END PGP SIGNATURE-
>
>

Re: Disasterous problem with 2 spec jars

[Brett Porter]

For the record...

Maven does not use the eclipse compiler without it being configured.
However, by default it is -source 1.3 and -target 1.1 (maximum JVM
compatibility). It's the -target 1.1 that adds these signatures.

Adding 1.4 and 1.4 fixed the issue.

- Brett

On 12/13/05, Kevan Miller <[EMAIL PROTECTED]> wrote:
> I don't fully understand the issue, but Eclipse may not be doing the wrong
> thing... Sun JDK 1.5 will, in fact, behave in the same manner (I haven't
> tested to see how 1.5 will compile the same class).
>
>  Just to be clear, the "near-term" options seem to be:
>
>  1) switch spec build to maven 1
>  2) configure maven 2 to use javac from Sun 1.4 (there are references to
> setting a compilerId in the maven-compiler-plug
>  3) challenge the test results
>
>  We should be able to easily determine if 2 will work... If not, then get
> started on 1...
>
>  --kevan
>
>
>
> On 12/13/05, Rick McGuire <[EMAIL PROTECTED]> wrote:
> > I just took a look at the Sun version of the BodyPart class, and it is
> > similarly truncated (although it supports a setParent() method in
> > addition to getParent()).  It appears that the eclipse compiler is
> > adding this incorrectly.  It makes sense that it shouldn't, since the
> > BodyPart class is abstract.  It NEEDS to leave all of the unimplemented
> > methods unimplemented to ensure that subclasses complete the concrete
> > class contract.
> >
> > Rick
> >
> > David Jencks wrote:
> >
> > > Sachin says that maven 2 uses the eclipse compiler rather than javac
> > > and that judging by its behavior when looking at binary classes in
> > > eclipse it may well be producing these bad class files.  It appears
> > > that all the methods in the "implements" interfaces have been added
> > > to  the class.
> > >
> > > Presumably the solution is to build with maven 1.
> > >
> > > If the eclipse compiler is in fact at fault, I think that this will
> > > prevent us from using maven 2 until either a javac compiler is
> > > provided  or the eclipse compiler is fixed.  If the eclipse compiler
> > > behavior is  actually according to the jdk spec we may have a
> > > different issue.
> > >
> > > thanks
> > > david jencks
> > >
> > >
> > > On Dec 13, 2005, at 1:11 AM, David Jencks wrote:
> > >
> > >> Something is dreadfully wrong with two of the spec jars build by
> > >> maven  2.
> > >>
> > >> The javamail BodyPart class  source looks like this:
> > >>
> > >>
> > >> package javax.mail;
> > >>
> > >> /**
> > >>  * @version $Rev: 54266 $ $Date: 2004-10-10 14:02:50 -0700 (Sun, 10
> > >> Oct 2004) $
> > >>  */
> > >> public abstract class BodyPart implements Part {
> > >> protected Multipart parent;
> > >>
> > >> public Multipart getParent() {
> > >> return parent;
> > >> }
> > >> }
> > >>
> > >> Decompiling the class (1951 bytes) from the maven 2 build gives this:
> > >>
> > >>
> David-Jencks-Computer:~/geronimo/geronimo/svn/geronimo/branches/1.0
> > >> david$ javap -classpath
> > >> ~/downloads/geronimo-javamail_1.3.1_spec-1.0.jar
> javax.mail.BodyPart
> > >> Compiled from " BodyPart.java"
> > >> public abstract class javax.mail.BodyPart extends java.lang.Object
> > >> implements javax.mail.Part{
> > >> protected javax.mail.Multipart parent;
> > >> public javax.mail.BodyPart ();
> > >> public javax.mail.Multipart getParent();
> > >> public abstract void writeTo(java.io.OutputStream);
> > >>throws java/io/IOException, javax/mail/MessagingException
> > >> public abstract void setText( java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setHeader(java.lang.String,java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setFileName( java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setDisposition(java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setDescription( java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setDataHandler(javax.activation.DataHandler);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setContent(
> java.lang.Object,java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract void setContent(javax.mail.Multipart);
> > >>throws javax/mail/MessagingException
> > >> public abstract void removeHeader(java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract boolean isMimeType(java.lang.String);
> > >>throws javax/mail/MessagingException
> > >> public abstract int getSize();
> > >>throws javax/mail/MessagingException
> > >> public abstract java.util.Enumeration
> > >> getNonMatchingHeaders(java.lang.String[]);
> > >>throws javax/mail/MessagingException
> > >> public abstract java.util.Enumeration
> > >> getMatchingHeaders(ja

Re: [Vote] Installer: Default Web Container Selection

[Brett Porter]

> [ x ] Make Jetty the default Web Container install selection

Non binding, but I like Jetty. Besides, given how close to a release
it is, it seems sensible to stick with it.

- Brett

Re: Plugin installation problems

[Brett Porter]

plugin:install-now is the same as plugin install, but it loads into
the running Maven and updates the cache, like using a plugin
dependency. You are right that they are probably incompatible.

plugin:repository-install is only useful if you are later using it as
a dependency. Maven doesn't use the repository for plugins otherwise,
and this goal doesn't affect the cache.

HTH,
Brett

On 12/4/05, David Jencks <[EMAIL PROTECTED]> wrote:
> We've been seeing severe plugin installation problems in the gbuild
> build; it looks like the plugins built in (the equivalent of )new1 are
> not available for use in (the equivalent of) new4 or new5.  After
> looking at some maven plugin plugin jelly code I think this might be
> because plugin:install and plugin:install-now are interfering with each
> other and that running both will never work.
>
> I've modified what we run in the plugins to this:
>
>  
>  
>  
>  todir="${maven.plugin.dir}" />
>   
>
>
> which IIUC should have the same effects as plugin:install
> plugin:install-now plugin:repository-install without the interference.
> However whether your build works after messing with plugins seems to be
> very dependent on what was there before, so please look out for and
> report problems.
>
> thanks
> david jencks
>
>

[jira] Commented: (GERONIMO-1286) Have CRLF line endings for zip distribution and LF line endings for tar.gz distribution

[Brett Porter (JIRA)]

[ 
http://issues.apache.org/jira/browse/GERONIMO-1286?page=comments#action_12359259
 ] 

Brett Porter commented on GERONIMO-1286:


third time I've seen this in the last couple of days... weird.

notepad seems to be about the only editor I've seen that isn't smart enough to 
figure this out, so I generally stick with the line endings on the release 
system, but making sure any batch files and shell files have the correct line 
endings regardless (as its possible the zip is used on unix, or the tar.gz on 
windows via cygwin).


> Have CRLF line endings for zip distribution and LF line endings for tar.gz 
> distribution
> ---
>
>  Key: GERONIMO-1286
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1286
>  Project: Geronimo
> Type: Improvement
>   Components: usability
> Versions: 1.0
> Reporter: John Sisson
> Assignee: John Sisson
>  Fix For: 1.0

>
> Previously, the line endings on files in a Geronimo distribution were based 
> upon the platform the distribution was built on.
> The build needs to be improved so that no matter what platform Geronimo is 
> built on:
> * the resulting distributions should contain the same files (no files 
> excluded)
> * the resulting zip distribution should have CRLF line endings for 
> viewable/editable text files and therefore is targeted at windows users.
> * the resulting tar.gz distribution should have LF line endings for 
> non-Windows platforms.  All non-Windows users should use the tar.gz file as 
> the tar file also contains permission settings for the files.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: IntelliJ JDK path

[Brett Porter]

I assume you are referring to David Jencks' version? All his changes
and more are in the latest release:

maven plugin:download -Dversion=1.6 -DartifactId=maven-idea-plugin
-DgroupId=maven

Cheers,
Brett

On 12/1/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
> Yeah...the IntelliJ plugin for maven is bad.  You need an updated version.
> I can email you one if you like.
>
> Jeff
>
>
> > -Original Message-
> > From: Ken Perl [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, November 30, 2005 7:37 PM
> > To: dev@geronimo.apache.org
> > Subject: IntelliJ JDK path
> >
> > Hi,
> > I build a IntelliJ project by using maven -o m:intellij and
> > can open the project in the IDE, the problem is I can't set
> > the classpath or use system's JDK for a module, while this
> > could be done in a new project, so I guess this is not
> > IntelliJ 's issue.
> > The result is many java symbols can't be resolved in the IDE.
> > Any thoughts?
> >
> >
> > --
> > perl -e 'print unpack(u,"62V5N\"FME;G\!E > ")'
> >
>
>
>

[jira] Created: (GERONIMO-1180) setup a periodic clean of published snapshots

[Brett Porter (JIRA)]

setup a periodic clean of published snapshots 
--

 Key: GERONIMO-1180
 URL: http://issues.apache.org/jira/browse/GERONIMO-1180
 Project: Geronimo
Type: Task
  Components: gbuild  
Reporter: Brett Porter


this should be something general for the apache repository. It needs to clean 
all snapshots over X days old, except for the one currently selected from 
maven-metadata.xml (meaning that there will be one retained per development 
branch)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: gbuild: snapshots publishing now

[Brett Porter]

No, I was just wondering. It would be worth JIRAing so it doesn't get
forgotten :)

It would be generally useful to have something that pruned all over X
days old and not the currently referred to snapshot.

- Brett

On 11/16/05, David Blevins <[EMAIL PROTECTED]> wrote:
> Not yet, do you have something?
>
> -David
>
> On Nov 15, 2005, at 5:40 PM, Brett Porter wrote:
>
> > Did you also set up something to periodically clean them?
> >
> > On 11/16/05, David Blevins <[EMAIL PROTECTED]> wrote:
> >> FYI, I setup an rsync script that pulls snapshots from the continuum
> >> setup and onto cvs.apache.org.
> >>
> >> So, if you want new snapshots published, the easiest way is to click
> >> the "Build Now" button and wait an hour or two (http://ci.gbuild.org/
> >> continuum/servlet/continuum).
> >>
> >> I set this up for Geronimo and OpenEJB (1 and 2).  Can set that up
> >> for ActiveIO, TranQL, etc. as well if the respective projects want.
> >>
> >> Need to get Devtools in there too.
> >>
> >> -David
> >>
> >
>
>

Re: gbuild: snapshots publishing now

[Brett Porter]

Did you also set up something to periodically clean them?

On 11/16/05, David Blevins <[EMAIL PROTECTED]> wrote:
> FYI, I setup an rsync script that pulls snapshots from the continuum
> setup and onto cvs.apache.org.
>
> So, if you want new snapshots published, the easiest way is to click
> the "Build Now" button and wait an hour or two (http://ci.gbuild.org/
> continuum/servlet/continuum).
>
> I set this up for Geronimo and OpenEJB (1 and 2).  Can set that up
> for ActiveIO, TranQL, etc. as well if the respective projects want.
>
> Need to get Devtools in there too.
>
> -David
>

Re: [openejb-scm] [continuum] BUILD FAILURE: OpenEJB 2

[Brett Porter]

http://ci.gbuild.org/continuum/servlet/continuum/target/WorkingCopy.vm/view/WorkingCopy/id/6?userDirectory=modules/openejb-builder/target/test-reports&file=TEST-org.openejb.corba.security.config.tss.TSSConfigEditorTest.txt
(http://tinyurl.com/797ke)

I seem to recall regular problems with TSSConfigEditorTest in setting
up the m2 build - can't remember what it was now, but I think it was
related to the JDK in use?

- Brett

On 11/15/05, David Jencks <[EMAIL PROTECTED]> wrote:
> I'm not able to reproduce this failure locally and I don't see how to
> access the test reports to see what is wrong.  Any ideas? Do others see
> this problem?
>
> thanks
> david jencks
>
> On Nov 14, 2005, at 9:43 PM, continuum wrote:
>
> > http://ci.gbuild.org/continuum/target/ProjectBuild.vm/view/
> > ProjectBuild/id/6/buildId/108
> >
>
>

Re: m2: flushing out our dependencies

[Brett Porter]

Hi David,

Certainly, they should be put into the main repository (via an
evangelism issue). For the specs ones, these are probably older than
trunk that has the poms - but I'd expect them to be the same or
similar - so definitely use those. They'll still need to be uploaded.

- Brett

On 11/12/05, David Jencks <[EMAIL PROTECTED]> wrote:
>
> On Nov 11, 2005, at 11:00 AM, Prasad Kashyap wrote:
>
> > I'm done creating poms for the 17 modules in the attached text file.
> >
> >  I was able to get some jars (same version and all) from the M1
> > repository. I need to track down the other jars.
> >
> >  Next I need to figure out how to create a patch from the repository
> > jars. TortoiseSVN doesn't seem to help me there. Any tips here would
> > be appreciated.
> >
> >  Should I create 1 JIRA for all these 17 modules or should each module
> > have it's own JIRA ?
> >
> >  Cheers
> >  Prasad
> >
> >
> >
> I'm worried  that duplicate work is happening.   The geronimo-specs
> already have an m2 build so I would  think they all have valid m2 poms.
>   I believe jeff genender has valid activemq poms from his work with
> wadi.
>
> I certainly don't know what should happen with these poms now that they
> exist.  I don't think keeping them private to geronimo is likely to be
> the best practice.  Should we open one issue/pom in maven evangelism?
> Jason? Brett?
>
> thanks
> david jencks
>
>

Re: Specs: Individual specs also in J2EE...

[Brett Porter]

>From a Maven point of view with transitive dependencies, this is
imperative. The universal jar should just be a distribution
convenience (if it is built at all).

- Brett

On 11/10/05, David Jencks <[EMAIL PROTECTED]> wrote:
> I have a REALLY REALLY REALLY strong preference that ALL geronimo
> modules depend ONLY on the specs they actually use.  I would prefer
> that we don't build the universal spec jar or that we build it after
> everything else is built and all the configurations are built.  I
> really prefer to know what specs a particular geronimo module depends
> on.
>
> thanks
> david jencks
>
> On Nov 9, 2005, at 8:51 PM, Aaron Mulder wrote:
>
> > So I notice that the JSR-88 code is in
> > geronimo-spec-j2ee-deployment-1.1-rc4.jar and also
> > geronimo-spec-j2ee-1.4-rc4.jar.  I guess "spec-j2ee" is a rollup of
> > all (or most of) the others?  Is there a preference for whether other
> > modules should depend on the individual spec modules or the overall
> > "spec-j2ee" module?
> >
> > Aaron
> >
>
>

Re: [consolidation] next steps?

[Brett Porter]

I'm not on the incubator PMC, so this is just my personal
understanding. I may be getting in over my head :)

On 11/9/05, Jules Gosnell <[EMAIL PROTECTED]> wrote:
> are you saying that these licensing constraints do not apply in the
> incubator - that we just dump all our code in there, no matter what,
> provided that licensing issues are resolved before promotion out of it ?

Sorry, I was unclear. I don't think I'd recommend this, but it is
possible as code in the incubator is covered by a disclaimer and no
releases can be made until IP and licensing has been cleared.

> please clarify 'depend on/include' - by this do you mean 'physically
> package together with your binary distribution' or 'import at compile
> time, into classes that are shipped in the binary distribution'.

I think both of these constitute a derivative work falling under the
GPL. As far as I know, the only way to combine with GPL applications
is by executing them in a separate process.

>
> > LGPL may be
> >possible, but only if optional and not distributed with the
> >application.
> >
> so it is OK to 'import' LGPL code at compile time, as long as you don't
> ship it ?
>
> > There is ongoing discussion around this.
> >
> >
> so it may not actually be OK :-) ?

right.
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200508.mbox/[EMAIL 
PROTECTED]

> thanks for helping with this.

No problem. I think it would be best to ask these questions of
[EMAIL PROTECTED] and legal-discuss when it comes to specifics.

Cheers,
- Brett

Re: Proposal: apache-wide specs project

[Brett Porter]

This is an interesting idea.

What scope do you envisage? Would it only be JSRs, or would, for
example, stdcxx in the incubator be able to join?

Do you see any issues with having a single project but specs that
encompass a variety of technologies that might not overlap?

I think it is fine to start with an org.apache.specs group either way
as it isn't going to clash with anything.

I think it would be good to discuss this more broadly, but I'm not
sure of a suitable apache wide list other than community@

- Brett

On 11/8/05, David Jencks <[EMAIL PROTECTED]> wrote:
> Many people have talked on and off about setting up an apache-wide
> specs project.  With the recent move to separate our copies of the
> specs and build them with maven 2 perhaps this is a good time to try to
> get this started.
>
> Here are some steps we could take:
>
> -Identify projects with java spec implementations in them.  They
> include at least:
>geronimo
>tomcat
>pluto (have already expressed interest)
>axis
>scout (?)
>
> --Approach the projects to see if they are interested
>
> --Appropriate the M2 groupId org.apache.specs
>
> --Based on the support we get  proposing a new top level project.  This
> is going to be an unusual project in that it's expected that changes
> will only take place when new specs come out :-)
>
> We could all start using the groupId org.apache.specs even before an
> actual project was set up.  This might just cause confusion though.
>
>
> Thoughts?
>
> many thanks
> david jencks
>
>

Re: [consolidation] next steps?

[Brett Porter]

This is one of the requirements of incubation, so it will be taken
care of there - but it's good for those communities to be aware of it
when making their decision.

The GPL doc you refer to is actually about the combining of ASL and
GPL works being possible at all, regardless of the requirements here.

The following are some guidelines, though it'd be best to consider
individual cases on legal-discuss@ which will have to happen during
incubation.

As for what you can depend on/include as an ASF project, GPL is not
possible because it affects the license of the whole. LGPL may be
possible, but only if optional and not distributed with the
application. There is ongoing discussion around this.

The key point is that the ASF retain its ability to distribute
software that doesn't have conditions beyond those in the ASL (yes,
there are some exceptions out there).

Cheers,
Brett

On 11/9/05, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> Even beyond the requirements of incubation, there exists a whole host
> of issues surrounding the use of code with a license other than AL. I
> know that ServiceMix  and WADI integrate such code. So how is this to
> be sorted out? For example, I know that the ASF has a long-standing
> policy on the use of GPL compatibility:
>
> http://www.apache.org/licenses/GPL-compatibility.html
>
> In addition to the whole GPL can of worms, how about the TranQL
> requirement for Oracle and DB2 JDBC drivers?
>

Re: [consolidation] next steps?

[Brett Porter]

This is an area of much confusion. This may help (or it may not :)

http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200508.mbox/[EMAIL 
PROTECTED]
(tiny: http://tinyurl.com/8fcx6)

Basic gist, as I understand (IANAL): the copyright is not assigned to
the ASF, but licensed to the ASF. This is done through a software
grant form.

If anyone is interested in this, you should review the thread above
and join the legal-discuss list which is open to all committers to ask
questions.

HTH,
Brett

On 11/8/05, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 11/7/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>
> > > b) the copyright must be assigned to the ASF
> >
> > I was told there was no way for someone to assign copyrights to the
> > ASF.  Has this changed and if so where is the form?
>
> That's a question for Noel. Let's allow him (or someone else in the
> know) some time to respond.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL 
> PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://geronimo.apache.org/
>

Re: How to identify a JIRA with a patch.

[Brett Porter]

The problem with this is that when a person later attaches a file,
they usually don't have permissions to edit the issue and adjust the
custom field, so it only works when the attachment comes with
creation.

Maybe this is something that could be added to the ASF customisations
though (the bit that makes them approve it is ASL'd) - maybe you could
propose this on infrastructure@ - Jeff Turner will likely be able to
offer an opinion.

- Brett

On 11/2/05, David Blevins <[EMAIL PROTECTED]> wrote:
> On Nov 1, 2005, at 2:04 PM, Joe Bohn wrote:
>
> > Is there any way to get a view of JIRAs that have files(patches)
> > attached?
> >
> > If not, can we begin some kind of convention?  I noticed that some
> > folks have added (Patch) to the start of the title for a few
> > JIRAs.  Do you think that would be helpful?
> >
> > I image it must be a pain for the committers to get a view of the
> > available patches.
> >
> > Any other suggestions?  Anybody how other projects manage this?
> >
>
> This just occurred to me, but I wonder if we couldn't add a "patch"
> custom field, which would be even better than knowing which jira
> items have files attached (as that's not even possible anyway).
>
> Assuming everyone used it, it would be really easy to find and report
> them then.
>
> Not exactly sure how custom fields work in JIRA, but I just noticed
> it glancing through the docs just now (http://www.atlassian.com/
> software/jira/docs/v3.3.2/customfields/overview.html)
>
> -David
>

Re: [continuum] BUILD SUCCESSFUL: Geronimo

[Brett Porter]

On 11/2/05, David Blevins <[EMAIL PROTECTED]> wrote:
>
> That's cool.  Continuum gets smart enough to do things like report
> which test failed, etc. when you are dealing with a maven 1 or 2
> project.  Up to you if that is worth the trade-off of loosing
> project.xml inheritance.  You can always poke at it later if you
> like.  You could also convert to m2 and keep the inheritance if you
> are interested in the "smarter" continuum support.

You shouldn't need to get rid of inheritence, just only build the
common root (which I thought you were doing anyway).

Note that this doesn't affect m2 at all as the parents are referenced
from the repository, not the file system.

Certainly a feature for Continuum 1.1.

>
> I'd really like to flatten the inheritance in Geronimo but there are
> like 40+ modules compared to 4 in the devtools.  I'm jealous :)

I don't think flattening is a good goal, its an important tool in
factoring the build correctly.

Cheers,
Brett

Re: How to identify a JIRA with a patch.

[Brett Porter]

Not as far as I know. I'm tracking a JIRA ticket at Atlassian for the
ability to detect the existence of an attachment, but that stiff
doen't designate if its a patch unfortunately.

In our project we just query for "patch" in any of the text fields. We
generally find that people type that somewhere when attaching it.

- Brett

On 11/2/05, Joe Bohn <[EMAIL PROTECTED]> wrote:
> Is there any way to get a view of JIRAs that have files(patches) attached?
>
> If not, can we begin some kind of convention?  I noticed that some folks
> have added (Patch) to the start of the title for a few JIRAs.  Do you
> think that would be helpful?
>
> I image it must be a pain for the committers to get a view of the
> available patches.
>
> Any other suggestions?  Anybody how other projects manage this?
>
> Joe
>

Re: [vote] gbuild subproject

[Brett Porter]

On 11/1/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> But I don't really understand what gbuild is yet.  Is this really
> Geronimo-centered, or broader with Geronimo as a piece?  Was there
> any thought given to Ken's suggestion of working with Gump since they
> do similar things?

Just on this - its quite a different problem space to gump. I'm not
sure about the current development, but the existing gump doesn't do
distributed builds, and is more of a massive integration test than a
continuous build tool.

It's certainly worth keeping in mind for the future as it develops,
but at least in my experience with Gump I don't notice any points of
collaboration yet. That said - it wouldn't hurt to bounce the message
over to the general@gump.apache.org list as an FYI.

Another note: as more projects start to depend on Geronimo libraries
(especially specs), it will be more important for them to be included
in Gump (I think some of them already are, but not all).

BTW, I think this gbuild setup is a great thing for Geronimo and
related projects, and also great feedback for the Maven project and
Continuum - I look forward to working with you and seeing what can
come out of it.

Cheers,
Brett

Re: Specs directory structure

[Brett Porter]

Not exactly. The soft version is the version that will be used if it
fits in the valid ranges, and ignored if not. The conflict resolver in
play decides whether to use the nearest or newest of these versions -
in 2.0 only "nearest" was enabled.

If you want to allow a range, you have to give it an actual range in
the dependency declaration.

We're certainly looking to make some improvements to this based on
experience in 2.1 which is in planning now - so I appreciate any
suggestions.

Either scheme will let you do what you want using a range whether it
is [2.4,2.5) or [1.0,); it's just a matter of what you find
friendliest and most manageable from a perspective of releasing the
specs.

Maybe this is better:

servlet-2.4-spec-1.0

Where 1.0 is the version, servlet-2.4-spec is the artifact Id.

Cheers,
Brett

On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>  From what I read on the maven wiki, you support soft versions, so
> using the style you described below would 2.4
> resolve to the newest 2.4* version you have in your local repo.  Is
> that accurate?
>
> -dain

Re: Specs directory structure

[Brett Porter]

Yes, version ranges work, but simply omitting the version won't do it.

You could have [2.4,2.5) to pick up 2.4, 2.4-1, 2.4-2, etc. though.

Cheers,
Brett

On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Oh, I thought one of the big features of m2 was support for version
> ranges.
>
> BTW I find the name servlet-2.4-1.0 confusing myself.
>
> -dain
>
> On Oct 31, 2005, at 12:10 PM, Brett Porter wrote:
>
> > Actually, I meant a version of 2.4-1, 2.4-2.
> >
> > I think there is advantages and disadvantages to each, so I'll let you
> > all decide what's best to work with. I just wanted to point out that
> > omitting the version won't work so it'll need to be specified, and
> > personally I'd find that a bit confusing presented with:
> >
> > servlet-2.4-1.0.
> >
> > - Brett
> >
> > On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> >
> >> Just to clarify you mean we should have this:
> >>
> >>org.apache.geronimo.specs
> >>servlet-2.4
> >>Geronimo :: Servlet API
> >>1
> >>
> >> So the version number is a single non-dotted increasing integer?
> >>
> >> BTW for most APIs we will be able to simply release a certified
> >> version and never update, but for some APIs, like JavaMail, are
> >> mostly implementation code, we will have to to patch releases.  Also
> >> if we get into the habit of adding JavaDoc documentation over time,
> >> we will have to do periodic release to get the line numbers in the
> >> debug symbols to match-up.
> >>
> >> -dain
> >>
> >> On Oct 30, 2005, at 9:29 PM, Brett Porter wrote:
> >>
> >>
> >>> I think this versioning has potential to be confusing, and the
> >>> omission of  below doesn't actually do that - though it is
> >>> probably possible with a version of (,) that includes everything.
> >>>
> >>> Personally, I'd prefer to have:
> >>> servlet-api-2.4
> >>> servlet-api-2.4-1
> >>> servlet-api-2.4-2
> >>> or similar.
> >>>
> >>> (Technically, the last "build number" is used for rebuilding the
> >>> same
> >>> source code, not patching, but I think the alternative of 2.4.x
> >>> creates some more confusion and the above will work as intended).
> >>> Ideally, once 2.4 is compliant you don't need to release it again
> >>> anyway :)
> >>>
> >>> Perhaps when we have proper spec-dependency handling in Maven it
> >>> might
> >>> be less confusing to use the geronimo-spec version number instead of
> >>> the spec number.
> >>>
> >>> My 2cents...
> >>>
> >>> - Brett
> >>>
> >>>
> >>> On 10/30/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> >>>> I know this has been talked about before on this list, but I'd like
> >>>> to get the proposal in one place.  With the help of Alan and Jason,
> >>>> this is what I got:
> >>>>
> >>>> Normally we just have this directory structure:
> >>>>
> >>>> specs/trunk/servlet-2.2/src/
> >>>> specs/trunk/servlet-2.4/src/
> >>>> specs/trunk/jsp-2.4/src/
> >>>> When we are happy with the specs we make a tag:
> >>>>
> >>>> specs/tags/1.0/servlet-2.2/src/
> >>>> specs/tags/1.0/servlet-2.4/src/
> >>>> specs/tags/1.0/javamail-2.2-r2/src/
> >>>> specs/tags/1.1/servlet-2.2/src/
> >>>> specs/tags/1.1/servlet-2.4/src/
> >>>> specs/tags/1.1/javamail-2.2-r2/src/
> >>>> The pom for the specs would be like this:
> >>>>
> >>>>org.apache.geronimo.specs
> >>>>  servlet-2.4
> >>>>  Geronimo :: Servlet API
> >>>>1.0
> >>>> With maven 2 version ranges a user can just have the following and
> >>>> maven will pick the most resent release of our spec automatically:
> >>>>
> >>>>
> >>>>  org.apache.geronimo.specs
> >>>>  servlet-2.4
> >>>>
> >>>>
> >>>> The current directory structure in https://svn.apache.org/repos/
> >>>> asf/
> >>>> geronimo/specs is very close to this.  The only big change will
> >>>> be to
> >>>> add the version number of the specification to the directory name.
> >>>>
> >>>> What do yo think?
> >>>>
> >>>> -dain
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>

Re: Specs directory structure

[Brett Porter]

Just re-reading that I realised it could be a bit confusing as 2.4-1
and 2.4-1.0 look very similar.

The difference is that the first would be:
servlet
2.4-1

as opposed to
servlet-2.4
1.0

I think this is an interesting thing to discuss and perhaps feed back
into the Maven default versioning rules to accommodate it in general
if there is something better that we can come up with.

- Brett

On 11/1/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> Actually, I meant a version of 2.4-1, 2.4-2.
>
> I think there is advantages and disadvantages to each, so I'll let you
> all decide what's best to work with. I just wanted to point out that
> omitting the version won't work so it'll need to be specified, and
> personally I'd find that a bit confusing presented with:
>
> servlet-2.4-1.0.
>
> - Brett
>
> On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> > Just to clarify you mean we should have this:
> >
> >org.apache.geronimo.specs
> >servlet-2.4
> >Geronimo :: Servlet API
> >1
> >
> > So the version number is a single non-dotted increasing integer?
> >
> > BTW for most APIs we will be able to simply release a certified
> > version and never update, but for some APIs, like JavaMail, are
> > mostly implementation code, we will have to to patch releases.  Also
> > if we get into the habit of adding JavaDoc documentation over time,
> > we will have to do periodic release to get the line numbers in the
> > debug symbols to match-up.
> >
> > -dain
> >
> > On Oct 30, 2005, at 9:29 PM, Brett Porter wrote:
> >
> > > I think this versioning has potential to be confusing, and the
> > > omission of  below doesn't actually do that - though it is
> > > probably possible with a version of (,) that includes everything.
> > >
> > > Personally, I'd prefer to have:
> > > servlet-api-2.4
> > > servlet-api-2.4-1
> > > servlet-api-2.4-2
> > > or similar.
> > >
> > > (Technically, the last "build number" is used for rebuilding the same
> > > source code, not patching, but I think the alternative of 2.4.x
> > > creates some more confusion and the above will work as intended).
> > > Ideally, once 2.4 is compliant you don't need to release it again
> > > anyway :)
> > >
> > > Perhaps when we have proper spec-dependency handling in Maven it might
> > > be less confusing to use the geronimo-spec version number instead of
> > > the spec number.
> > >
> > > My 2cents...
> > >
> > > - Brett
> > >
> > >
> > > On 10/30/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> > >
> > >> I know this has been talked about before on this list, but I'd like
> > >> to get the proposal in one place.  With the help of Alan and Jason,
> > >> this is what I got:
> > >>
> > >> Normally we just have this directory structure:
> > >>
> > >> specs/trunk/servlet-2.2/src/
> > >> specs/trunk/servlet-2.4/src/
> > >> specs/trunk/jsp-2.4/src/
> > >> When we are happy with the specs we make a tag:
> > >>
> > >> specs/tags/1.0/servlet-2.2/src/
> > >> specs/tags/1.0/servlet-2.4/src/
> > >> specs/tags/1.0/javamail-2.2-r2/src/
> > >> specs/tags/1.1/servlet-2.2/src/
> > >> specs/tags/1.1/servlet-2.4/src/
> > >> specs/tags/1.1/javamail-2.2-r2/src/
> > >> The pom for the specs would be like this:
> > >>
> > >>org.apache.geronimo.specs
> > >>  servlet-2.4
> > >>  Geronimo :: Servlet API
> > >>1.0
> > >> With maven 2 version ranges a user can just have the following and
> > >> maven will pick the most resent release of our spec automatically:
> > >>
> > >>
> > >>  org.apache.geronimo.specs
> > >>  servlet-2.4
> > >>
> > >>
> > >> The current directory structure in https://svn.apache.org/repos/asf/
> > >> geronimo/specs is very close to this.  The only big change will be to
> > >> add the version number of the specification to the directory name.
> > >>
> > >> What do yo think?
> > >>
> > >> -dain
> > >>
> > >
> >
> >
>

Re: Specs directory structure

[Brett Porter]

Actually, I meant a version of 2.4-1, 2.4-2.

I think there is advantages and disadvantages to each, so I'll let you
all decide what's best to work with. I just wanted to point out that
omitting the version won't work so it'll need to be specified, and
personally I'd find that a bit confusing presented with:

servlet-2.4-1.0.

- Brett

On 11/1/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Just to clarify you mean we should have this:
>
>org.apache.geronimo.specs
>servlet-2.4
>Geronimo :: Servlet API
>1
>
> So the version number is a single non-dotted increasing integer?
>
> BTW for most APIs we will be able to simply release a certified
> version and never update, but for some APIs, like JavaMail, are
> mostly implementation code, we will have to to patch releases.  Also
> if we get into the habit of adding JavaDoc documentation over time,
> we will have to do periodic release to get the line numbers in the
> debug symbols to match-up.
>
> -dain
>
> On Oct 30, 2005, at 9:29 PM, Brett Porter wrote:
>
> > I think this versioning has potential to be confusing, and the
> > omission of  below doesn't actually do that - though it is
> > probably possible with a version of (,) that includes everything.
> >
> > Personally, I'd prefer to have:
> > servlet-api-2.4
> > servlet-api-2.4-1
> > servlet-api-2.4-2
> > or similar.
> >
> > (Technically, the last "build number" is used for rebuilding the same
> > source code, not patching, but I think the alternative of 2.4.x
> > creates some more confusion and the above will work as intended).
> > Ideally, once 2.4 is compliant you don't need to release it again
> > anyway :)
> >
> > Perhaps when we have proper spec-dependency handling in Maven it might
> > be less confusing to use the geronimo-spec version number instead of
> > the spec number.
> >
> > My 2cents...
> >
> > - Brett
> >
> >
> > On 10/30/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> >
> >> I know this has been talked about before on this list, but I'd like
> >> to get the proposal in one place.  With the help of Alan and Jason,
> >> this is what I got:
> >>
> >> Normally we just have this directory structure:
> >>
> >> specs/trunk/servlet-2.2/src/
> >> specs/trunk/servlet-2.4/src/
> >> specs/trunk/jsp-2.4/src/
> >> When we are happy with the specs we make a tag:
> >>
> >> specs/tags/1.0/servlet-2.2/src/
> >> specs/tags/1.0/servlet-2.4/src/
> >> specs/tags/1.0/javamail-2.2-r2/src/
> >> specs/tags/1.1/servlet-2.2/src/
> >> specs/tags/1.1/servlet-2.4/src/
> >> specs/tags/1.1/javamail-2.2-r2/src/
> >> The pom for the specs would be like this:
> >>
> >>org.apache.geronimo.specs
> >>  servlet-2.4
> >>  Geronimo :: Servlet API
> >>1.0
> >> With maven 2 version ranges a user can just have the following and
> >> maven will pick the most resent release of our spec automatically:
> >>
> >>
> >>  org.apache.geronimo.specs
> >>  servlet-2.4
> >>
> >>
> >> The current directory structure in https://svn.apache.org/repos/asf/
> >> geronimo/specs is very close to this.  The only big change will be to
> >> add the version number of the specification to the directory name.
> >>
> >> What do yo think?
> >>
> >> -dain
> >>
> >
>
>

Re: Specs directory structure

[Brett Porter]

I think this versioning has potential to be confusing, and the
omission of  below doesn't actually do that - though it is
probably possible with a version of (,) that includes everything.

Personally, I'd prefer to have:
servlet-api-2.4
servlet-api-2.4-1
servlet-api-2.4-2
or similar.

(Technically, the last "build number" is used for rebuilding the same
source code, not patching, but I think the alternative of 2.4.x
creates some more confusion and the above will work as intended).
Ideally, once 2.4 is compliant you don't need to release it again
anyway :)

Perhaps when we have proper spec-dependency handling in Maven it might
be less confusing to use the geronimo-spec version number instead of
the spec number.

My 2cents...

- Brett


On 10/30/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> I know this has been talked about before on this list, but I'd like
> to get the proposal in one place.  With the help of Alan and Jason,
> this is what I got:
>
> Normally we just have this directory structure:
>
> specs/trunk/servlet-2.2/src/
> specs/trunk/servlet-2.4/src/
> specs/trunk/jsp-2.4/src/
> When we are happy with the specs we make a tag:
>
> specs/tags/1.0/servlet-2.2/src/
> specs/tags/1.0/servlet-2.4/src/
> specs/tags/1.0/javamail-2.2-r2/src/
> specs/tags/1.1/servlet-2.2/src/
> specs/tags/1.1/servlet-2.4/src/
> specs/tags/1.1/javamail-2.2-r2/src/
> The pom for the specs would be like this:
>
>org.apache.geronimo.specs
>  servlet-2.4
>  Geronimo :: Servlet API
>1.0
> With maven 2 version ranges a user can just have the following and
> maven will pick the most resent release of our spec automatically:
>
>
>  org.apache.geronimo.specs
>  servlet-2.4
>
>
> The current directory structure in https://svn.apache.org/repos/asf/
> geronimo/specs is very close to this.  The only big change will be to
> add the version number of the specification to the directory name.
>
> What do yo think?
>
> -dain
>

Re: deploying snapshots

[Brett Porter]

I think you need to set:

maven.repo.*.group=apcvs

(where * is the repo name you used)

- Brett

On 10/26/05, Sachin Patel <[EMAIL PROTECTED]> wrote:
> Think i figured it out... however when its attempting to upload...
>
>  [echo]
>Executing cd
> /www/cvs.apache.org/repository/geronimo-devtools/poms; chmod g+w
> org.apache.geronimo.devtools.eclipse.core-0.5.0-SNAPSHOT.pom; chgrp
> maven org.apache.geronimo.devtools.eclipse.core-0.5.0-SNAPSHOT.pom with
> the username sppatel on apache.org
>
> Password:
>  [exec] chgrp: you are not a member of group maven
>
> Geir, could you add me to this group?
>
> Sachin
>
> Sachin Patel wrote:
> > I'm wanting to update the tooling build to be able to deploy snapshots
> > to the remote repo... Could someone point me to an example from the
> > geronimo tree where and how this goal is being configured?
> >
> > Thanks
> >
> > Sachin
> >
>

Re: Is this ok? (was [DO NOT USE OR PROPAGATE THE LINK ON THE ANNOUNCEMENT] Re: [ANN] Geronimo 1.0 milestone 5 (M5) released))

[Brett Porter]

The main problem with this is that you can never get to the backup
mirrors (try clicking the bottom links).

I think you need to announce the
http://geronimo.apache.org/downloads.html page. That gives you the
most freedom to change links later.

Cheers,
Brett

On 10/5/05, David Blevins <[EMAIL PROTECTED]> wrote:
> On Oct 4, 2005, at 6:38 AM, Geir Magnusson Jr. wrote:
>
> > We're really excited about this release, and got a little ahead of
> > ourselves.  We need to let the code propagate out to our mirrors,
> > so please don't publish the link below, but rather go to our
> > mirrors via the download page :
> >
> > http://geronimo.apache.org/downloads.html
> >
> > Again, please do not publish the link below.
> >
>
> http://www.apache.org/dist/geronimo/1.0-M5/geronimo-1.0-M5-src.tar.gz
> http://www.apache.org/dist/geronimo/1.0-M5/geronimo-1.0-M5-src.zip
> http://www.apache.org/dist/geronimo/1.0-M5/geronimo-1.0-M5.tar.gz
> http://www.apache.org/dist/geronimo/1.0-M5/geronimo-1.0-M5.zip
> http://www.apache.org/dist/geronimo/1.0-M5/geronimo-installer-1.0-M5.jar
>
> Is this cool with everyone?  I just added an .htaccess file to
> redirect these URLs to the mirrors page (try and see).  I took a look
> around and saw a bunch of the Jakarta projects doing similar redirects.
>
> We can maybe take it down after the flood of downloads is over.  Or
> now if someone doesn't like it.  Or never.  But with that it should
> be ok to publish any variety of "http://www.apache.org/dist/geronimo/
> 1.0-M5" link.
>
> -David
>
> > On Oct 4, 2005, at 8:50 AM, Jeff Genender wrote:
> >
> >
> >> With great pleasure the Apache Geronimo Team would like to
> >> announce the official release of Milestone 5 (M5) of Apache
> >> Geronimo. The release is available at:
> >>
> >> http://www.apache.org/dist/geronimo/1.0-M5
> >>
> >> Significant Changes Since the M4 Release
> >> 
> >>  * Complete Tomcat integration (YAY!)
> >>  * Configuration of ports, hosts, and most other attributes
> >> without rebuilding the server
> >>  * A web management console (developer preview)
> >>  * Official J2EE Certification (as soon as paper work is filed)
> >>
> >> Special Thanks
> >> --
> >>  * Thanks to the community for all of their input and patches to
> >> help get us to where we are at.
> >>
> >>  * Aaron Mulder for all his work on console to get it in a usable
> >> state.
> >>
> >>  * The ActiveMQ guys for helping out with the bugs and burning the
> >> midnight oil to help get the release out in a timely fashion.
> >>
> >>  * Dims for getting the patches into Axis.
> >>
> >>  * Gianni for fixing up TranQL and CMP issues
> >>
> >>  * A BIG HUGE thanks for David Blevins and David Jencks for
> >> working with me into the wee-hours of the night, testing and
> >> getting Geronimo to pass the TCK tests for both the Jetty *and*
> >> Tomcat containers.  These guys really stepped up and didn't leave
> >> me hanging with Tomcat issues for my lonesome ;-)
> >>
> >>  * Everyone else on the team who contributed and worked crazy
> >> hours to get this release out. (If your name was not
> >> mentioned...this means you).
> >>
> >> Full release notes are available here:
> >>
> >> http://www.apache.org/dist/geronimo/1.0-M5/RELEASE-NOTES-1.0-M5.txt
> >>
> >>
> >> --
> >> Jeff Genender
> >> http://geronimo.apache.org
> >>
> >>
> >>
> >>
> >
> > --
> > Geir Magnusson Jr  +1-203-665-6437
> > [EMAIL PROTECTED]
> >
> >
> >
>
>

Re: Weird HEAD build problem, maven 1.0.2

[Brett Porter]

On 10/2/05, David Jencks <[EMAIL PROTECTED]> wrote:
> so you are saying this works in 1.0.2 in one multiproject build, and
> the reactor will figure out the correct order?

The order is only if you use the plugin dependency - in this case, you
need to use plugin:repository-install.

That's my understanding as how it should work. If it doesn't work
first go, I wouldn't experiment either :)

> or did I misunderstand?  I've spent several days trying to get this to
> work in the past so I'm not too keen to spend a lot of time
> experimenting.

Fair enough - it seems it works fine as is after a second attempt or
if the plugin is individually installed, so its workable without it.

- Brett

Re: Weird HEAD build problem, maven 1.0.2

[Brett Porter]

I think this was more the case that it works on the second run because
the plugin is installed?

Plugin dependencies should do what you want and work in maven 1.0.2+.
When using a dependency, you only need to call
plugin:repository-install (install to repo, not Maven) instead of
plugin:install (which doesn't work in the same instance). Another
alternative is plugin:install-now (installs permanently, and into the
running instace).

And yes, all plugins are plugin dependencies in m2 and this works out
of the box.

HTH,
Brett

On 10/2/05, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> It looks like it's fixed in Maven 1.1 beta 2.  I guess we ought to
> push everyone in that direction.
>
> Thanks,
> Aaron
>
> On 10/1/05, David Jencks <[EMAIL PROTECTED]> wrote:
> > This is a symptom of a different problem, that you can't build a plugin
> > and use it in the same build (at least not reliably, as far as I can
> > tell)  magicGball now uses the deployment plugin which has deploy-jsr88
> > as a dependency.  If the plugin isn't built you will get a related
> > error when you get to assembly.
> >
> > It might help to include a dependency on the deploy plugin in
> > project.xml.  However, I have faint memories that this might cause
> > other problems.  In general I've found maven 1 to have problems
> > building a plugin and using it in the same multiproject build.  I don't
> > know if this is fixed in maven 1.1, I believe it is fixed in maven 2.
> >
> > Wish I had better news,
> > david jencks
> >
> > On Oct 1, 2005, at 8:09 AM, Aaron Mulder wrote:
> >
> > > When I do a rebuild-all on HEAD, I get (eventually):
> > >
> > > +
> > > | Executing default The Magic G Ball
> > > | Memory: 67M/83M
> > > +
> > > You are working offline so the build will continue, but
> > > geronimo-common-1.0-SNAPSHOT.jar may be out of date!
> > > You are working offline so the build will continue, but
> > > geronimo-kernel-1.0-SNAPSHOT.jar may be out of date!
> > > You are working offline so the build will continue, but
> > > geronimo-deployment-1.0-SNAPSHOT.jar may be out of date!
> > > You are working offline so the build will continue, but
> > > geronimo-system-1.0-SNAPSHOT.jar may be out of date!
> > >
> > > BUILD FAILED
> > > File..
> > > /Users/ammulder/.maven/cache/maven-multiproject-plugin-1.3.1/
> > > plugin.jelly
> > > Element... maven:reactor
> > > Line.. 217
> > > Column 9
> > > The build cannot continue because of the following unsatisfied
> > > dependency:
> > >
> > > geronimo-deploy-jsr88-1.0-SNAPSHOT.jar
> > >
> > > Total time: 4 minutes 44 seconds
> > > Finished at: Sat Oct 01 10:53:15 EDT 2005
> > >
> > >
> > > I don't understand why it wants geronimo-deploy-jsr88 even though
> > > that's not listed as a dependency in project.xml for the magic G ball.
> > >  In any case, if that's a prerequisite, shouldn't something force the
> > > deploy-jsr88 module to be built before the magic G ball module?
> > >
> > > Thanks,
> > > Aaron
> > >
> >
> >
>

Re: Snapshots in M5

[Brett Porter]

On 9/25/05, David Jencks <[EMAIL PROTECTED]> wrote:
> servicemix_version=1.0-SNAPSHOT

Both 1.0 and 1.0.1 are on the main repository

> apacheds_version=0.9.2-SNAPSHOT
> asn1_version=0.3.2-SNAPSHOT
> ldap_protocols_version=0.9.2-SNAPSHOT

> Directory guys are there any non-snapshot versions we can use?

Yes, 0.9.2 and 0.3.2 (asn1) are both released.

Cheers,
Brett

Re: M5 - 24hr notice of branch

[Brett Porter]

I'm interested to find out what that is - it was significantly faster for me (due to the reduced memory consumption). I also can't think of what would have changed to trigger that other than the upgrade to Ant 1.6 (which would be doing the deletes and uptodate checks) and seems a long shot.
- BrettOn 9/19/05, Aaron Mulder <[EMAIL PROTECTED]> wrote:
It does seem a little slower to me (for example, deleting dirs on arebuild or working through modules that are already current for aregular build), but I don't have numbers to back it up.  :)AaronOn 9/18/05, Dain Sundstrom <
[EMAIL PROTECTED]> wrote:> None that I have found yet.>> -dain>> On Sep 18, 2005, at 11:47 AM, Geir Magnusson Jr. wrote:>> > Any reason why I wouldn't want to use 
1.1-b2?> >> > geir> >> > On Sep 16, 2005, at 9:06 PM, Dain Sundstrom wrote:> >> >> >> I committed the patch and have been using 1.1-b2 for about a week
> >> now.> >>> >> -dain> >>> >> On Sep 16, 2005, at 6:01 PM, Brett Porter wrote:> >>> >>> >>> >>> I believe Dain committed them the other day.
> >>>> >>> Cheers,> >>> Brett> >>>> >>> On 9/17/05, Aaron Mulder <[EMAIL PROTECTED]
 >> >>> wrote:Brett,> >>> Have the changes been committed that make the Geronimo> >>> HEAD work> >>> with 1.1-b2?  Last time I noticed, you said we had some POMs that
> >>> were not> >>> valid I think.> >>>> >>> Thanks,> >>> Aaron> >>>> >>> On Fri, 16 Sep 2005, Brett Porter wrote:
> >>> > Special request from the Maven team:> >>> >> >>> > those doing deployment to java-repository using jar:deploy> >>> (this does not> >>> > affect normal users), please ensure you are using maven-
> >>> artifact-plugin> >>> > 1.5.2 or above.> >>> >> >>> > If you are using 1.1-beta-2, it comes with the latest version.> >>> >
> >>> > If you are using 1.0.2, you must install it. You can check what> >>> you have> >>> > with maven --info.> >>> >> >>> > To install:
> >>> > maven plugin:download -DartifactId=maven-artifact-plugin -> >>> DgroupId=maven> >>> > -Dversion=1.5.2> >>> >> >>> > The reason for doing this is that all ${versions}, %entities
> >>> and > >>> > elements will be properly resolved so the POM will be complete,> >>> and will> >>> > enable Geronimo for transitive dependencies for Maven 
2.x users> >>> - this is> >>> > especially important if there are any new spec JARs going up.> >>> >> >>> > Thanks! If I can help any further, please let me know.
> >>> >> >>> > Cheers,> >>> > Brett> >>> >> >>> >> >>> > On 9/16/05, Jeff Genender < 
[EMAIL PROTECTED]> wrote:> >>> > >> >>> > > The subject says it all ;-)> >>> > >> >>> > > Jeff> >>> > >
> >>> >> >>>> >>>> >>>> >>> >>> >>> >> > --> > Geir Magnusson Jr  +1-203-665-6437
> > [EMAIL PROTECTED]> >> >>>

Re: M5 - 24hr notice of branch

[Brett Porter]

I believe Dain committed them the other day.Cheers,BrettOn 9/17/05, Aaron Mulder <[EMAIL PROTECTED]
> wrote:Brett,Have the changes been committed that make the Geronimo HEAD work
with 1.1-b2?  Last time I noticed, you said we had some POMs that were notvalid I think.Thanks,AaronOn Fri, 16 Sep 2005, Brett Porter wrote:> Special request from the Maven team:
>> those doing deployment to java-repository using jar:deploy (this does not> affect normal users), please ensure you are using maven-artifact-plugin> 1.5.2 or above.>> If you are using 
1.1-beta-2, it comes with the latest version.>> If you are using 1.0.2, you must install it. You can check what you have> with maven --info.>> To install:> maven plugin:download -DartifactId=maven-artifact-plugin -DgroupId=maven
> -Dversion=1.5.2>> The reason for doing this is that all ${versions}, %entities and > elements will be properly resolved so the POM will be complete, and will> enable Geronimo for transitive dependencies for Maven 
2.x users - this is> especially important if there are any new spec JARs going up.>> Thanks! If I can help any further, please let me know.>> Cheers,> Brett>>> On 9/16/05, Jeff Genender <
[EMAIL PROTECTED]> wrote:> >> > The subject says it all ;-)> >> > Jeff> >>

Re: M5 - 24hr notice of branch

[Brett Porter]

Special request from the Maven team:those doing deployment to java-repository using jar:deploy (this does not affect normal users), please ensure you are using maven-artifact-plugin 1.5.2 or above.If you are using 
1.1-beta-2, it comes with the latest version.If you are using 1.0.2, you must install it. You can check what you have with maven --info.To install:maven plugin:download -DartifactId=maven-artifact-plugin -DgroupId=maven -Dversion=
1.5.2The reason for doing this is that all ${versions}, %entities and  elements will be properly resolved so the POM will be complete, and will enable Geronimo for transitive dependencies for Maven 
2.x users - this is especially important if there are any new spec JARs going up.Thanks! If I can help any further, please let me know.Cheers,BrettOn 9/16/05, 
Jeff Genender <[EMAIL PROTECTED]> wrote:
The subject says it all ;-)Jeff

Re: mirroring our downloads

[Brett Porter]

Done - originals are in archive.apache.org and ~brett/geronimo-poms and ~/geronimo-spec-poms (some of these had older releases that were also invalid).Thanks!- Brett
On 9/14/05, Brett Porter <[EMAIL PROTECTED]> wrote:
On 9/8/05, Brett Porter <[EMAIL PROTECTED]> wrote:

For the old releases, once they appear in archive.apache.org, you can
probably delete them from www.apache.org (this will mean they aren't
mirrored, but available from the archive).

Can I ask that you delete the M2 and M3 POMs from java-repository? They
aren't independantly valid or useful and Maven's repository management
has started to squawk. Recent versions of the Maven artifact deployment
plugin will properly resolve the variables in them to make them useful
for future releases.
Does anyone mind if I do this? Other than redeploying those releases using a newer version of the artifact plugin that resolves the entities and parent poms, I don't see an easy way to get these corrected.
Thanks,Brett

Re: mirroring our downloads

[Brett Porter]

On 9/8/05, Brett Porter <[EMAIL PROTECTED]> wrote:
For the old releases, once they appear in archive.apache.org, you can
probably delete them from www.apache.org (this will mean they aren't
mirrored, but available from the archive).

Can I ask that you delete the M2 and M3 POMs from java-repository? They
aren't independantly valid or useful and Maven's repository management
has started to squawk. Recent versions of the Maven artifact deployment
plugin will properly resolve the variables in them to make them useful
for future releases.
Does anyone mind if I do this? Other than redeploying those releases using a newer version of the artifact plugin that resolves the entities and parent poms, I don't see an easy way to get these corrected.
Thanks,Brett

[jira] Updated: (GERONIMO-987) build fixes to work with maven 1.1 beta 2

[Brett Porter (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-987?page=all ]

Brett Porter updated GERONIMO-987:
--

Attachment: GERONIMO-987.diff

> build fixes to work with maven 1.1 beta 2
> -
>
>  Key: GERONIMO-987
>  URL: http://issues.apache.org/jira/browse/GERONIMO-987
>  Project: Geronimo
> Type: Bug
>   Components: buildsystem
> Reporter: Brett Porter
>  Attachments: GERONIMO-987.diff
>
> Attached is a patch to some build files that are not quite valid and that the 
> new Maven beta is stricter on.
> releases are expected to be official soon, and can be tested from here:
> http://people.apache.org/~brett/release/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-987) build fixes to work with maven 1.1 beta 2

[Brett Porter (JIRA)]

build fixes to work with maven 1.1 beta 2
-

 Key: GERONIMO-987
 URL: http://issues.apache.org/jira/browse/GERONIMO-987
 Project: Geronimo
Type: Bug
  Components: buildsystem  
Reporter: Brett Porter


Attached is a patch to some build files that are not quite valid and that the 
new Maven beta is stricter on.

releases are expected to be official soon, and can be tested from here:
http://people.apache.org/~brett/release/

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: mirroring our downloads

[Brett Porter]

On 9/8/05, David Blevins <[EMAIL PROTECTED]> wrote:
I've moved over all our milestones to www/www.apache.org/dist/ andwww/www.apache.org/dist/java-repository.  I assume those will bemirrored to Ibiblio and other places by tonight.  
For the old releases, once they appear in archive.apache.org, you can
probably delete them from www.apache.org (this will mean they aren't
mirrored, but available from the archive).

Can I ask that you delete the M2 and M3 POMs from java-repository? They
aren't independantly valid or useful and Maven's repository management
has started to squawk. Recent versions of the Maven artifact deployment
plugin will properly resolve the variables in them to make them useful
for future releases.
How do we go aboutgetting one of those fancy "pick a mirror" selection boxes on our
download page?
The simplest thing is to use dyncloser.cgi for the links:
http://www.apache.org/dyn/closer.cgi/geronimo/1.0-M4/geronimo-1.0-M4.tar.gz

That gives you a separate page to select from. The dropdowns mean using a customised CGI, I believe - but I've never tried it.

Some docs:
http://www.apache.org/dev/mirrors.html
http://www.apache.org/dev/mirror-step-by-step.html

http://www.apache.org/dev/mirror-guide-bodewig.html

Cheers,
Brett

Re: eclipse Distribution site proposal

[Brett Porter]

Geir,

Since this is under cvs.apache.org and not www.apache.org/dist (and
hence not mirrored), it isn't a problem. Nobody has had a problem with
snapshots under cvs.apache.org/repository, AFAIK.

- BrettOn 8/31/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
There's been concern elsewhere that the concept of "snapshot" that'sthen distributed is a way of circumventing the oversight of arelease.  I want to be sure that the nightly-ness of this is clear,especially if the eclipse people are linking to it.
On Aug 30, 2005, at 1:20 PM, Dain Sundstrom wrote:> Geir this code is in cvs.apache.org under a directory called> "unstable".  This is exactly how we do nightly unstable "r"eleases.
>> Regardless, if this is a real concern for you, simply delete the> directory as I instructed.>> -dain>> On Aug 30, 2005, at 9:55 AM, Geir Magnusson Jr. wrote:>
>>> my concern is that this might be interpreted as a de-facto release>> of some sort.  Can it be named something like "nightly" or such? On Aug 30, 2005, at 12:44 PM, Dain Sundstrom wrote:
> Since on one objected I uploaded the site from GERONIMO-949 to here:>> http://cvs.apache.org/dist/geronimo/eclipse/unstable
>> If any committer has an objection, just delete this directory on>>> people.apache.org:>> /www/cvs.apache.org/dist/geronimo/eclipse/unstable
>> and then we can address the concerns.>> -dain>> On Aug 29, 2005, at 5:36 PM, Dain Sundstrom wrote:>>
>> On Aug 29, 2005, at 4:52 PM, Sachin Patel wrote:> It may take some time to get the subproject website set up and
> I'm still working on getting the plugins mavenized.  In the> meantime could we either set up a distribute update site on> Geronimo or even easier just post the latest distribution zip
> on the main site?  I've already sent a note out to the WTP dev> list informing them that it will be posted on Apache soon.>> Thoughts?
 +1 I suggest we create the eclipse site here:
 http://cvs.apache.org/dist/geronimo/eclipse/unstable If you can create the site and upload it to JIRA as a patch,
 I'll post it to the site (assuming no one objects). -dain>>
>> -->>
Geir Magnusson
Jr  +1-203-665-6437>> [EMAIL PROTECTED]--Geir
Magnusson
Jr  +1-203-665-6437[EMAIL PROTECTED]

Re: progress on mavenizing eclipse plugins

[Brett Porter]

Geir,

Plan for this is to have the m2 CLI detect project.xml and run Maven
1.1 embedded. I think I had this mostly working, but it hasn't been
bundled with a release yet. I'll take another look.

- BrettOn 8/30/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
On Aug 29, 2005, at 2:18 PM, Geir Magnusson Jr. wrote:>> Also, will M2 build M1 projects?  (Oh, please, please, please say> it will...)According to the maven site, it can't.I'm going to see if I can install both, and create a maven shell
script that figures out what the project is, and invokes the correctversion of maven...--Geir
Magnusson
Jr  +1-203-665-6437[EMAIL PROTECTED]

Re: maven question

[Brett Porter]

Hi Sachin,

It may be worth posting this to the Maven Users list, there are
several folks that can help out there.

The problem here is that "plugin" is a reserved type for Maven
plugins. Also note that / should not be valid in a groupId - they are
meant to be identifiers, not path elements - and when converted to a
different layout the / or .jar in artifactId would cause confusion.

I'd suggest using a type = jar (which is the default). There is little
advantage to having a separate type.

I'd also suggest using groupId = org.eclipse.core, artifactId =
org.eclipse.core.resources, version = 3.1.0.

This will give you a filename almost what you want, except that _ will
be replaced with -. This is just how Maven deals with its repository -
you are able to rename the file when you reuse it in Eclipse after it
has been downloaded.

Hope this helps.

Cheers,
Brett

On 8/29/05, Sachin Patel <[EMAIL PROTECTED]> wrote:
> I'm playing around trying to declare a dependency on an eclipse plugin
> purely using the  element.  Theres are 2 problems in doing so...
> 
> If I have the following
> 
> 
> eclipse
> org.eclipse.core.resources
> 3.1.0
> plugin
> 
> 
> This according to the documentation would resolve to
> [REPO_ROOT]/eclipse/plugins/org.eclipse.core.resources-3.1.0.plugin
> 
> rather then [REPO_ROOT]/eclipse/plugins/org.eclipse.core.resources_3.1.0.jar
> 
> Notice the two differences, (1) where  will be used as the
> extension rather then .jar, and (2) the version number for eclipse
> plugins are appended with an underscore rather then a dash.
> 
> Is the  element required? Can I just change groupID to
> eclipse/plugins and then also remove the version
> number and have the full artifact file name specified
> org.eclipse.core.resources_3.1.0.jar ?
> 
> Thanks.
>

Re: [mevenide-dev] Help building eclipse plugins

[Brett Porter]

This might seem a little crazy, but perhaps both :) The project.xml (+
properties) and pom.xml files hopefully should not be too different
and can sit side by side. As long as those differences are within
reason this is probably a realistic choice - but it depends on what
you are able/want to work with.

The Maven2 OSGi plugin is being developed at Apache Felix by Tim
Bennett. I'm sure he'd love some feedback.

There is a Maven1 plugin at http://mavenosgiplugin.berlios.de/

Hopefully that's all the information you need to go one way or the
other. Please let me know if I can be of any help.

Cheers,
Brett

On 8/28/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> I agree with Jeff that one Maven would be better.  When we do the move
> to M2 I don't think an additional poject will make that much difference
> but having to Mavens would a bit frustrating.
> 
> - Matt
> 
> Jeff Genender wrote:
> 
> > Sachin,
> >
> > maven 1 can use a lot of your ant stuff too (just looks a bit wierd).
> > You don't always have to rely on the plugin - for example the maven
> > xdoclet plugins are too restrictive.  Its easy to just do a taskdef
> > and throw in your ant tasks.
> >
> > If I had my druthers, I would stick with M1 so it will build with
> > everything.  Although there is a plan to move to M2, those target
> > dates are unknown.  It would be nice to have the plugin build under
> > M1, with the rest of G.  I think it would be a bit much to have the
> > end user have to download m1 and m2 to build all of G.
> >
> > Jeff
> >
> > Sachin Patel wrote:
> >
> >> So, Gilles doesn't recommend modeling the build for the geronimo
> >> eclipse plugins after the Mevenide plugin, as he thinks its grown way
> >> too complex, plus it doesn't support OSGI bundles.  The geronimo
> >> server adapter are already defined as OSGI bundles anyways so this is
> >> problem as I wouldn't to revert away from OSGI as this would force me
> >> to use deprecated Eclipse APIs.
> >>
> >> He mentions trying to use the maven-osgi-plugin, but the M2 version
> >> of it, which of course Geronimo hasn't moved to M2 yet.  Will the
> >> move to M2 be a post 1.0 item?
> >>
> >>
> >>
> >>
> >>
> >> 
> >>
> >> Subject:
> >> Re: [mevenide-dev] Help building eclipse plugins
> >> From:
> >> Gilles Dodinet <[EMAIL PROTECTED]>
> >> Date:
> >> Sat, 27 Aug 2005 16:19:21 +0200
> >> To:
> >> [EMAIL PROTECTED]
> >>
> >> To:
> >> [EMAIL PROTECTED]
> >>
> >> X-Account-Key:
> >> account3
> >> X-Gmail-Received:
> >> 6f5b36182ff4c4ed96e5a06c71c259bdee55bbd1
> >> Delivered-To:
> >> [EMAIL PROTECTED]
> >> Received:
> >> by 10.36.121.19 with SMTP id t19cs9894nzc; Sat, 27 Aug 2005 07:15:40
> >> -0700 (PDT)
> >> Received:
> >> by 10.54.63.12 with SMTP id l12mr4524333wra; Sat, 27 Aug 2005
> >> 07:15:40 -0700 (PDT)
> >> Return-Path:
> >> <[EMAIL PROTECTED]>
> >> Received:
> >> from codehaus.org (beaver.codehaus.org [64.7.141.17]) by mx.gmail.com
> >> with SMTP id 14si2776555wrl.2005.08.27.07.15.39; Sat, 27 Aug 2005
> >> 07:15:40 -0700 (PDT)
> >> Received-SPF:
> >> pass (gmail.com: domain of
> >> [EMAIL PROTECTED] designates
> >> 64.7.141.17 as permitted sender)
> >> Received:
> >> (qmail 6124 invoked by uid 7924); 27 Aug 2005 14:21:21 -
> >> Mailing-List:
> >> contact [EMAIL PROTECTED]; run by ezmlm
> >> Precedence:
> >> bulk
> >> List-Post:
> >> 
> >> List-Help:
> >> 
> >> List-Unsubscribe:
> >> 
> >> List-Subscribe:
> >> 
> >> Reply-To:
> >> [EMAIL PROTECTED]
> >> Delivered-To:
> >> mailing list [EMAIL PROTECTED]
> >> Received:
> >> (qmail 5606 invoked from network); 27 Aug 2005 14:21:06 -
> >> Message-ID:
> >> <[EMAIL PROTECTED]>
> >> User-Agent:
> >> Mozilla Thunderbird 1.0 (Windows/20041206)
> >> X-Accept-Language:
> >> en-us, en
> >> MIME-Version:
> >> 1.0
> >> References:
> >> <[EMAIL PROTECTED]>
> >> In-Reply-To:
> >> <[EMAIL PROTECTED]>
> >> Content-Type:
> >> text/plain; charset=ISO-8859-1; format=flowed
> >> Content-Transfer-Encoding:
> >> 7bit
> >>
> >>
> >> sachin,
> >>
> >> right now maven-eclipse-eclipse-plugin is used in conjunction with
> >> m1. however this plugin has grown big and now exposes too many
> >> configuration properties and thus is now way too complex. besides
> >> that it doesn't support osgi bundle packaged plugins so it may
> >> probably not fit your needs. months ago i had started to reimplement
> >> it targetting m2 but had no time to finish the task. luckily enough
> >> matthew pryor has started too to write a m2 plugin to build eclipse
> >> plugins (search maven-dev list for "help with custom lifecyle"
> >> thread). i don't know the exact status of this plugin though.
> >>
> >> another alternative could be to use maven-osgi-plugin - haven't tried
> >> m1 version, m2 version' howto can be found here :
> >> http://tinyurl.com/8cjkv (in particular it needs a modified
> >> m